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Advanced  Avionics  Architecture  &  Technology  Review 
Achievement  of  Success 

Tliis  review  was  tasked  to  assess  currently  available  and  emerging  technologies 
that  are  relevant  to  Naval  avionics  acquisition.  The  review  fosters  a  Naval 
Aviation  “vision”  for  delivering  the  best  avionics  capability  to  the  Fleet.  The 
vision  encompasses  the  kev  enabling  technologies  to  be  used  as  building  blocks 
and  the  four  principal  thrusts  that  become  the  “pillars**  for  the  successful 
implementation  by  trained  personnel  of  die  Naval  Aviation  Systems  Team  and 
industry.  The  report  fulfills  the  tasking  and  provides  the  vision,  findings,  and 
recommendations  as  summariied  below. 


^  Affordable  AvIoDks  ^ 
to  meet  Fleet  Operadoiiial  Ncedi 


Naval  Aviation  Systems  Team 


Vision 


Overview 


Findings 

•  No  single  architecture  will  meet  all  avionics  requirements. 

•  System  complexity  demands  the  use  of  a  rigorous  systems  engineering  methodolo^. 

•  Industry  suppcats  DOD's  use  of  an  open  systems  af^roach. 

•  Use  of  published  standards  will  increase  contract  competition  and  lower  cost. 

•  Modular  avionics  will  lower  systems  develqpmem  and  suiqxm  cost 

•  A  bansidon  to  commercial  technologies  and  products  will  save  government  development 
and  support  dollars. 

•  High  payoffs  are  projected  if  sensor  design  standards  ate  updated  and  followed. 

•  Affordake  system  development  wiU  d^nd  on  an  unproved  software  development 
process. 

•  Software  reuse  capabili^  wUl  enhance  systems  affordability  only  if  matured. 

•  Ada  should  remain  DOD's  software  language  of  choice. 

•  Joint  service  acquisition  makes  sense. 

•  Technology  insotion  can  be  made  affordable. 


These  findings  cun  be  consolidated  into  aaingle  conclusion: 


The  best  inetfaoddlogy  for  designing  naval  aviation's  avionics  systems  is  a 
wen  defined  stanfhmls  baited  awroach.  applied  fluouiih  a  rigorons  systems 
MginccringjnahQdttogv. 


Recommendations 

Based  on  the  findings  of  this  study,  the  following  recommendations  are  made.  Itis 

recommended  that  the  Navy: 

•  Transition  ficm  the  use  of  multiple  unique  avionics  point  dmdgns  to  an  architectural 
approach  that  capitalizes  on  open  system  <q}pcituniti(»  and  joint  inidatives. 

•  Become  more  active  in  the  stuidards  orgaiii^ons  that  are  reqxxisible  for  iqiplicable  open 
system  standards. 

3r  Establish  a  limited  number  of  ardiitcctural  choices  through  a  managed  program  of 
technology  tracking,  standards  selection,  risk  assessment  and  technicel  trade-off  studies. 

•  Continue  to  promote  the  use  of  COTS  tkdutology  and  products  in  military  systems. 

•  Adopt  a  strategy  for  managing  optimal  COTS  use  . 

•  Enhmice  our  committment  to  joint  service  inograms. 

•  Support  the  Avionics  Engirteeiing  Sub-bo^  of  the  JACG 

>  Invest  in  the  software  development  in&asmicture  now  —  to  establish  long  term  software 
affordability. 

•  Establish  a  formal  system  engineering  process  to  guide  architectural  choice,  engineering 
standards  selection,  and  implementation  of  cost-effective  technological  solutions  for  Navy 
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Master  Table  of  Content*; 


Executive  Summary  -  Presents  the  top  level  findings  and  recommendations  of 

the  study. 

(Intended  for  all  levels  of  decision  makers  involved  with 
avionics  acquisition). 


Volume  One:  -  Avionics  Technology  provides  a  review  of  key  avionics 

technologies,  processes  and  development  programs. 

(Intendedfor  technical  decision  makers  and  to  serve  as 
an  executive  referervee  for  avionics  technologies). 


Volume  Two:  -  Avionics  SvstemsJEneineermg  presents  an  overview  of 

Systems  Engineoing  and  discusses  its  application  to 
avionics  acquisition. 

(Intendedfor  av'''  nics  managers ,  systems  integrators, 
and  systems  design  engineers) 


Volume  Three:  -  Industry  Survey  Responses  presents  industry’s  response 

to  an  intensive  avionics  de  relopment  questionnaire. 


Note:  Volume  Three  is  published  separately  and  is  limited  to  US. 
Government  Distribution  Only  due  to  extensive  use  of 
proprietaryicompetition  sensitive  irformation. 
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Executive  Summary 


EXECUTIVE  SUMMARY 


Purpose 


I  COM  of  tircnA 
I ...  intefiMion 
COM*  M«  Mwettive  mmI  reiult 

ia  pretiMied  profi 


modtficition  popoMti. 
TIhsm  prolilcflii  tie  partially 
due  to  a  lack  of  a  oonunon 
aircraft  arcftiiecatre.  ...* 


The  purpose  of  this  study  was  to  review  the  current  technology 
base,  developing  technologies,  and  the  potential  to  apply  them  to 
meet  miUtaiy  avionics  requirements.  Tht  review  also  examined  the 
technology  integration  methods  used  in  the  avionics  community  in 
order  to  develop  a  more  efficient  and  more  affordable  avionics 
archltectiual  snategy  for  the  future. 


VftOMJX>.Tnltla.USN 

3/2/92 


Background 


The  Navy  continues  to  make  a  significant  invesonent  in  complex 
avionics  systems  that  are  develop^  uniquely  for  Navy  aircraft.  It 
must  be  determined  whether  the  Navy  can  transfer  more  of  this 
investment  burden  to  industry  and  still  meet  requirements. 
Controlling  costs,  while  still  acquiring  leading-edge  technologies, 
requires  a  well  thought  out  plan  for  managing  future  investments^ 
Help  was  needed  to  understand  emerging  technologies  and  predict 
their  usefulness  to,  and  availability  for,  naval  avionics  applications. 

To  begin  formulating  this  plan,  a  team  of  government  avionics 
experts  was  assembled.  The  team  developed  and  executed  a 
research  and  information  gathering  strategy  which  polled  industry 
to  determine  present-day  and  future  technology  trends  in  advanced 
avionics.  The  second  phase  required  a  smictured  analysis  to 
identify  important  findings  and  consensus  positions.  During  this 
phase,  issues  such  as  multi-mission  platforms,  extending  life 
capability,  and  compatibility  with  other  Navy  systems  and  other 
services  were  addressed.  The  third  phase  involved  formulating 
individual  foldings  and  recommendations  which  are  the  principle 
products  of  this  report 

Industry  provided  a  significant  and  enthusiastic  response  by 
participating  in  a  technical  survey  that  contributed  greatly  to  this 
effort 
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Findings 


No  Single  - 
Architecture  Will 
Meet  All  Avionics 
Requirements 


AtyJiliTftBTw; 

faMMtponta  ttw  eompleie  wt  of 
focton  that  eoniributa  to  making  ae 
avionici  mile  into  a  ayalem  that 
wofki  ai  a  tanified,  hmetional 
whole  to  aooampUali  the  miiaion  of 
ihe  airarafL 


No  single  avionics  architecture  can  be  both  cost-effective 
and  functionally  efficient  when  forced  to  perform  all 
missions  or  fit  all  applications. 

A  single  architecture,  rigidly  applied,  limits  necessary 
design  flexibility  among  platforms  and  discourages  timely 
technology  insertion. 

Architecture  choice  is  driven  by  operadonal  requirements, 
environmental  requirements,  and  the  legacy  of  older 
aircraft 

Industry  supports  specifying  a  limited  number  of  open 
architectures  from  which  to  work. 


It  was  found  that  the  range  of  functional  needs  arriong  platforms  is 
so  diverse  that  no  known  architecture  would  satisfy  all 
requirements.  The  goal  of  a  single  architecture  to  meet  the  most 
demanding  user  requirements  would  necessarily  add  unnecried 
capabilities  to  other  user's  applications,  driving  costs  prohibitivelx. 
upward.  Additionally,  a  single  architecture  hinders  design 
optimization  and  flexibility.  On  the  other  hand,  too  many 
andiitectural  choices  can  obscure  standardization,  also  driving  costs 
upward.  To  achieve  cost-effective  and  efficient  solutions  to 
arionics  applications,  a  balance  must  be  struck. 

The  Navy  must  be  knowledgeable  on  all  the  various  building 
blocks  that  become  available  for  avionics  applications.  These 
building  block  elements  usually  represent  today's  state-of-the-art 
technologies  that  continue  to  evolve.  At  the  same  time,  the  Navy 
has  a  uttique  challenge. 

The  Navy  must  balance  affordability,  diverse  and  changing 
requirements,  emerging  threats  and  the  fact  that  industry  focuses 
mi  technology  trends  that  have  the  greatest  potential  benefit  in 
oommercial  nuher  than  military  markets. 


Executive  Suounary 


System  Complexity 
Demands  The  Use 
Of  A  Rigorous 
Systems 
Engineering 
Methodology 


Sytumt  Engiiieering; 

"An  mtefdlMpliiiary  approich  to 
evolve  ead  venfy  ea  ime|i*ted  aiid 
life-cycle  belenc^  eel  of  tyeiemi 
product  end  proceef  eolulloiw  thet 
leUifiei  ctutonier  necdc.  " 
(MIL-STO-499B) 


•  Most  industi^  respondents  suggested  a  formal,  disciplined 
systems  engineering  process  to  manage  a  more  standards 
based  approach  to  complex  systems  design. 

•  An  Integrated  Product  Development  Team  (IPDT)  approach 
involving  the  customer  (Navy),  the  prime  contractor,  and 
subcontractors  was  recommended  by  industiy. 

•  Current  acquisition  regulations  are  a  stumbling  block  to  an 
effective  integrated  product  development  team  approach. 

•  Systems  engineering  ensures  that  software  development, 
reuse,  and  metrics  are  part  of  the  total  systems  design  and 
development  effort 

•  Encourage  computer  based  modeling  and  simulation,  as 
part  of  the  systems  engineering  process,  to  reduce  cost  and 
risk. 


For  •  dcttiled  ditmuian  of 
iyMfnu  •agiMwlH,  mm 
Volume  2  of  thii  report. 


For  t  deuiled  diicuuion  of 
Syetemi  Engioeering  tool*  roe 
Volume  I,  aectioM  9- 1  A  9-3.S 
of  thii  report. 


The  Systems  engineering  process  provides  the  means  for  effective 
selection  and  application  of  standi^.  Figure  1  depicts  the  role  of 
the  systems  engineering  process  to  manage  and  evolve  both 
products  and  standards.  An  architecture  is  designed  by  carefully 
considering  requirements  and  constraints  such  as  cost  t^ets.  Just 
as  it  was  with  hardware,  software  development  is  undergoing 
transition  from  an  art  to  an  engineering  science  which  must  be 
embraced  as  a  key,  cost>savings  part  of  the  systems  engineering 
process. 

Systems  engineering  environments  provide  tools  used  in  each 
aspect  of  the  acquisition  process  from  simulation  programs  used  in 
the  conceptual  phase  to  life  cycle  cost  models  to  compare  the 
overall  cost  throughout  the  expected  service  life  of  the  system. 
Computerized  tools  do  not  replace  good  systems  analysis. 


Figure  1:  Overview  of  a  Standards-based  Systems  Engineering 
PnxxKs  for  Avionics  ArchitecUire  Development 


Advanced  A>donics  Archiiecbue  &  Technok^  Review 


Industty  Supports 
DoD's  Use  Of  An 
Open  Systems 
Approach 


Industry  supports  an  open  systems  standards-based 
approach  as  the  best  potential  method  to  reduce  cost,  risk, 
and  devel^ment  time,  while  increasing  inter  operability 
opportunities. 

Indusuy  supports  standard  interfaces  for  common  avionics 
modules,  standard  data  buses  and  switched  networks. 


OpnSyiUBi: 

One  aut 

nibUcly  ivtilable  qicctficitkiiM  for 
ncetftoM,  lerviOM,  tad  mppoittog 
fonuti  tc  tnaUe  |ifcp«dy 
cagiawml lo 
openit  with  odMa- ccmpoMau  on 
loetl  aad  teoMle  tyitenu,  to 
iaiena  irilli  luen  in  a  ttyk  which 
ftcQiittct  pofuUUty,  tad  (0  be 
MdUied  eerau  a  wiit  Mage  of 
lyneou  widiiiuniBial  du^e. 


For  a  daiaUad  diicuttioa  of 
o|]eai  qriMM  naadtiiit 
irdiilecttOT  aiffoacbM.  tee 
VokiBMl.MGlioo3*5. 


•  Open  systems  standards  support  a  modultur  building  block 
approach. 

•  An  open  systems  standards-based  approach  allows  the  use 
of  commetcially-available  products  for  rapid  prototyping. 

Technical  advances  can4)e  more  readily  accommodated,  without 
adversely  affecting  existing  overall  systems  design,  by  adopting  an 
open  systems  standards  approach.  The  Navy  will  realize  cost 
savings  because  an  open  systems  approach  allows  us  to  take 
advantage  of  commercial  standards  and  their  associated  products 
and  technology. 

The  open  systems  standards  approach  is  not  without  problems, 
however;  it  is  not  a  panacea.  For  example,  in  many  open  standards 
diere  are  user-defined  features,  certain  nmcdons,  memory  locations 
or  connectors  pins  that  can  be  ^plied  differendy  by  different  users 
of  these  standards.  This  design  flexifailky  can  und^ut  the  sought- 
after  attributes  of  interppetability  and  interchangea^Qr, 


Blindly  following  open  systems  standards  without  a  plan  will  not 
save  the  Navy  money.  We  must  track  the  selected  open  suindards 
to  ensure  that  Navy  requirements  and  needs  are  adchessed. 
Promoting  the  use  of  a  complementary  and  limited  set  of  open 
standards  will  prevent  an  excessive  number  of  choices  and  promote 
rational  standmdization  among  avionics  systems. 


4 


Executive  suintm;y 


Proper  Use  Of 
Published  Standards 
Will  Increase 
Contract 
Competition  and 
Lower  Cost 


Intarfaw  Suadardi: 

Smdudf  which  define  tad  eoMiol 
how  aTchiieGiiinl  building  blocki 
connea  etecnroaiGally,  Utennelly, 
mechniciUy,  elc.,  eiiKiag  the 
tyuemi  Ihet  we  develop. 

Synsni  Staadaidi: 

Sundatdf  that  eddioM  gtobel  iimei 
■ocfa  u  lyttan*  lecuiiiy,  power 
dhtilbuiioa,  lyuem  dUgnottici  end 
ihoie  for  iwruni  level 
euppoiUbility,  04..  MIL-STD  704. 


Piooeu  Siiodiidi: 

Siandwdt  diet  eddieti  end  define 
the  meihodi  end  pnoodiUM 
employed  e«  eynemi  ere 
deveuiwd.  Bxemplei  indude  Ihote 
that  govern  eoftwaie  development 
and  lyeiem  ae^neeiing  proeett. 


The  most  effective  way  to  obtain  commonality  among  the 
architectural  building  blocks  is  to  select  architectures  based  on  a 
family  of  interface,  system  and  process  standards.  These 
standards  build  a  hamewoi^  for  an  integrated  avionics  suite.  They 
should  cover  the  areas  of  data  prc^essors,  signal  processors,  RF 
electronics,  sensors,  and  the  various  buses  and  networks  that 
interconnect  these  building  blocks.  Interface  standards  must  deid 
with  software  as  well  as  h^ware.  In  addition,  selected  standards 
should  be  diverse  enough  to  meet  Navy  needs,  limited  enough  to 
support  commonality,  and  flexible  enough  to  pcnnit  designers 
freraom  to  be  creative  (yet  still  be  logistically  supportable).  The 
recommended  order  of  precedence  to  be  used  when  applying 
engineering  standards  to  new  and  existing  systems  is: 

a)  Open  Systems  Standards  controlled  by  non-government 
standards  bodies 

b)  Wldely-used  standards  under  government  control 

c)  Standards  controlled  by  special  purpose  working  groups 

d)  Proprietary  standards  for  unique  interfaces 

where  the  selection  process  is  the  result  of  an  enginecaing  analysis 
diat  has  considered  die  overall  merits  and  shortcmaings  of  each  for 
the  application. 

Use  of  standards  lowers  cost  by  increasing  contract  compeddon. 
By  breaking  the  overall  system  into  modular  building  blocks,  die 
system  integrator  (or  the  Navy)  is  able  to  compeddvely  buy  the 
component  blocks  from  a  variety  of  different  vendors.  By 
establishing  interface  and  systems  standards,  these  blocks,  built  Iw 
different  vendors,  can  be  quickly  integrattri  to  form  the  overaU 
system.  With  well  defined  standards  and  reasonably  small  building 
blocks,  a  medium  sized  company  can  rind  a  niche  need,  develop  a 
module  at  compwy  expense  to  fill  that  need,  and  market  t&it 
module  for  use  in  a  number  of  different  systems.  Ckimmerciai 
industry  feels  strongly  that  futore  module  reliability,  and  the 
eventual  ability  to  bimd  modules  to  standards  with  software  that  is 
instruction  set  architecture  indiqrendent,  will  lead  to  the  military's 
ability  to  significantly  reduce  logistics  costs.  A  failed  module  bimt 
by  one  vendor  can  then  be  replaced  by  a  module  built  by  a  second 
vendor,  possibly  using  a  more  power^  next  generation  processor, 
built  to  be  form,  fit,  and  interface  compatible  through  the  use  of 
standards. 

Another  factor  which  will  help  lower  cost  is  dual  commerdal  and 
military  use  of  the  standards.  Dual  use  has  been  difficult  in  tiie  past 
because  items  built  to  commercial  standards  have  often  not  satiffied 
Navy  requirements.  This  problem  can  be  partially  alleviated  by 
early  Na'^  participation  in  commercial  standards  development  in 
order  to  ensure  that  Navy  requirements  are  considered.  The  Next 
Generation  Computer  Resource  (NGCR)  program  followed  this 
approach. 
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Modular  Avionics 
Will  Lower  Systems 
Development  And 
Support  Cost 


A  signiidcant  trend  in  avionics  design  is  a  move  tiom  current 
federated  systems  (interconnected  black  boxes)  to  highly  modular, 
integrated  systems  with  a  high  degree  of.  sensor  data  sharing. 
Modular  packaging  has  become  the  preferred  approach,  where 
practical,  because  it  provides  for  effective  use  of  i»wcdul  high 
density  microelectronics,  increased  maintainability,  effective 
cooling  techniques,  and  offers  the  design  feature  of  backplane 
communications  using  standard  data  paths  and  data  buses. 


For  non  iofaniMikM  on 
ptoyrtti  wiminmi  looduUf 
integniad  aidiilecauret.  tee 
Volmiiel,  dii|Mnt. 


PorodmUrddircMiiian  < 
of  Modalif  Avionici  mo 
VolaBM2,Maiaal7. 


•  Modular  integrated  architectures  can  reduce  overall  avionics 
weight,  volume  and  power  requirements  while  permitting 
cost-effective  fault  tolerance. 

•  Modular  integrated  architectures  can  lower  recurring 
procurement  costs  ^  allowing  hardwtue  and  software  asset 
sharing. 

•  Modularity  provides  a  cost-effective  means  of  selective 
technolo^  insertion. 

Early  modeling  and  simulation  of  systems  will  vididate  design 
assumptions,  predict  system  performance  against  standira 
benchmarics,  and  test  changes  before  committing  to  a  specific 
design.  ModulariQr  makes  it  easier  to  create  and  maintain  usable 
systems  models. 


The  attributes  of  military  modular  avionics  systems  (building 
blocks)  are  being  explm^  by  organizations  such  as  the  Navy 
Standard  Hardware  and  Reliability  Program  (SHARP). 
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A  Transition  To 
Commercial 
Technologies  and 
Products  Will  Save 
Government 
Development  And 
Support  Dollars 


The  majority  of  indusby  iesp<mdents  believe  that  COTS 
avionics  should  provide  signiricant  cost  savings  nnd 
risk  reduction  for  functional  mras  that  aoe  common  to 
both  commercial  and  military  airoaft. 

DoD  should  cooperate  with  industry  in  establishing 
standards. 

Use  of  appropriate  commercial  technology  and  products 
provide  for  incorporation  of  continual  technical 
advancements  at  minimal  cost  to  the  government 


COWtMrctal  offmHMUMlf 

(COTS): 

Hatdwaie  awl  toAware  pntdiicu, 
leclmology  mkI  dMigni  MrehMcd 
ihraugh  eonmefcUl  icull  or 
wbcimto  UiniftMoci  u  if : 
BKxUaMl  to  (Mat  qpadfiad 
hmfrional  laquiiaiiwiu;  or 
fttggadiaed  lo  naei  farvke 
lequiientnii. 


•  Use  of  COTS  allows  for  early  prototyping,  early 
system  debug,  and  earlier  software  development  to 
rkluce  total  system  development  time,  risk  and  cost 

•  Satisfying  stringent  avionics  environmental  and  unique 
wstem-level  requirements  is  a  sigrdficant  challenge  for 
COTS,  Ixit  the  challenge  can  be  met 

Industry  stressed  the  need  to  leverage  commercial 
advancements  in  the  electronics  and  information  technology 
industries.  Judicious  use  of  COTS  hardware  (including 
Tuggedized  and  militarized  variants)  and  software  offers  several 
benefits:  a)  a  larger  qualified  suppliers  list,  b)  a  greater  ability 
to  "test  drive"  new  technologies  before  committing  huge  scarce 
financial  resources  to  a  full-scale  program,  and  c)  the  ability  to 
leverage  a  strong  commercial  user  base  to  accommodate 
changes  requested  by  fleet  users  at  lower  cost 


But  there  are  also  disadvantages  to  COTS  in  militaiy 
applications.  For  example,  few  commercial  systems  require 
n^ti-level  securify  or  nera  to  maintain  real-time  operations  in  a 
rigorous  environment  Addition  of  these  features  can  lead  to  a 
significant  level  of  redesign,  which  reduces,  the  economic 
advantages.  CXJTS  is  not  usually  designed  specifically  for 
environments  equivalent  to  those  seen  by  mUitary  avionics.  To 
compensate  for  this,  rigorous  testing  of  COTS  must  include 
environmental,  inter  operability  and  integration  testing  to 
predict  integral^  perfonnance  and  reliability  necessary  for  life- 
cycle  planning.  ^TS  solutions  might  actually  rrquire  more 
testing  than  unique  military  solutions  because  lack  of  detailed 
documentation  and  Navy  monitoring  during  the  design  phase 
reduces  our  knowledge  of  the  system. 


Figure  2  shows  the  relative  levels  of  potential  cost  avoidance  at 
several  different  levels  of  COTS  technology. 
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COMMERCIAL  PRODUCTS 
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Hgure2:  Inverse  Relationship  Between  Cost  Avoidance  and 
OOTS  Utilization 


To  achieve  standaidizadon  and  r^uircdpeifcnniance.  Efiecdve 
“ — selection  criteria  and  engineering  guidelines  for  the  use  of 

COTS  in  rdlitary  avionics  are  needed-  Differences  between 
nALuy«vkiidci,M»  vXiMi.  Commercial  standards  and  mUiti^  needs  have  the  greatest 
Nctois  sA  '  chance  of  reconciliation  if  the  military  actively  participates  in 

■■■■“ . .  commercial  standards  development  working  groups. 
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JDAeVUUVV  ISIUIIIIIW/ 


High  Payoffs  Ars 
Projected  If 
Sensor  Design 
Standards 
Updated  And 
Followed 


•  Industry  concurs  that  a  method  of  RF  interface 
standaituzation  should  be  applied  to  the  sensors  domain. 

•  State-of-the-art  avionics  is  heading  towards  greater 
miniaturization,  high  speed  networks!  distributed 
processing  and  intepated  sensors. 

•  Application  of  circuit  technolo^r  ftom  the  MIMIC  program 
can  provide  both  performance  gains  and  cost  savings  at  the 
sensor  head  (front  end)  for  RF  sensor  systems. 

•  Functions  such  as  sensor  fusion  will  be  more  easily 
performed  in  intepated  systems. 

•  Aircraft  sensor  technology  and  design  has  been  driven  by 
DoD  needs. 


Industry  reported  that  between  sixty  and  seventy  percent  of 
avionics  cost  is  attributed  to  sensor  ^sterns.  This  claim  is  based 
on  historical  analyses  of  federated  systems.  Federated  systems 
require  autonomous  capability  to  pIO^^  fuiictionality,  driving  up 
sensor  ^stem  cost  and  complexity.  In  newer  integrated  avionics 
systems,  modular  avionics  techniques  can  potentially  reduce  sensor 
costs  by  performing  much  of  the  signal  ptrocessing  using  standard* 
diglod  signal  processing  nodules  looted  in  avionics  compartments 
remote  fmm  me  analog  sensor  heads. 

The  retrofit  of  newer  sensor  technology  subsystems  into  older 
aircraft  requires  careful  consideration.  The  benerits  of  the 
technology  gains  could  be  outweighed  by  other  factors  such  as  the 
need  for  advanced  cooling  techniques  and/or  increased  data 
processing  requirements  in  excess  of  what  is  available  in  that 
specific  toKlel  aircraft 

Although  DoD  has  driven  sensor  technology  in  the  past,  this 
situation  is  changing.  Increased  comrnercial  sensor  iq^li^tions  in 
areas  such  as  meteorology,  medical  imaging,  video 
teleconferencing,  geological  and  geographical  mapping,  and 
communications  are  now  stimulating  commercial  development  of 
sensor  technologies.  Because  of  a  common  need  for  developing 
th^  technologies,  cooperative  development  and  cost  sharing  may 
soon  be  a  reality. 
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Aj^ordable  System 
Development  Will 
Depend  On 
Improved  Software 
Development 
Processes 


The  scale  and  scope  of  software  development  is  often 
underestimated  at  the  start  of  full-scale  development  for 
major  programs.' 

Systems  functionality  is  moving  from  hardware  to 
software.  This  movement  is  accelerated  as  systems  move 
from  federated  to  integrated  architectures. 


Modem  Naval  aircraft  weapon  systems  incorporate  complex 
avionics  systems  whose  core  functions  are  implemented  with 
software-intensive  subsystems  that  are  dependent  on  the  real-dme 
processing  of  information  and  data,  llie  development  of  the 
software  is  often  more  of  a  cost,  schedule,  and  risk  driver  at  the 
program  level  than  is  the  hardware.  Although  software  is 
perceived  to  be  distinct  from  hardware,  the  software  engineering 
process  must  be  part  of  the  overall  systems  engineering  process. 

The  maturity  of  an  organization's  software  engineering  capability 
can  be  measured  in  terms  of  the  degree  to  which  the  success  of  the 
next  software  development  can  be  predicted.  To  be  successful, 
oiganizadons  must  be  able  to  accurately  predict  the  amount  of  time, 
resources,  and  cost  required  to  develop  software.  One  measure  of 
an  organization's  software  engineering  capability,  which  the 
review  team  and  industry  both  endorsed,  is  the  Capability  Maturity- 
Model  (CMM)  developed  by  the  DoD  Software  Engineering 
Institute  (SEI). 


Softwan  EntiMMtttng  Itttdiuic't 
CtpakiSty  Miwtiqr  Modal  «M 
VohuM  1,  MOiod  M.1 


The  CMM  addresses  the  disciplines  and  processes  which  should  be 
in  place  for  an  organization  to  produce  reliable  software  in  a  timely 
and  cost  effective  manner,  lire  model  rests  on  the  premise  that 
software  process  maturity  is  a  credible  indicator  of  capability  and 
that  the  productivity  and  quality  resulting  from  an  organization's 
software  process  can  be  m^peavei  over  time. 


The  CMM  has  five  levels  of  maturity  and  describes  Key  Process 
Areas  (KPAs)  which  must  be  in  place  to  reach  the  next  higher 
maturity  level.  Ihe  five  levels  ate  Initial  (Level  1),  Refieatwle 
(Level  2),  Defined  (Level  3),  Managed  (Level  4),  and  Optimizing 
(Level  S).  Achieving  the  next  higher  level  of  process  maturity 
indicating  both  greater  control  of  an  organization's  softw^ 
process  and  greau^  consistency  with  which  the  ptroess  is  iqrpiied 
in  projects  throughout  the  organization.  The  higher  the  level 
achieved,  the  more  predictable  is  an  organization's  software 
process.  A  well  de^ed  and  planned  software  measurement 
program  is  required  to  progress  through  the  levels  of  the  CMM.  A 
noted  wealmess  of  the  C^M  is  its  failure  to  account  for  domain 
knowledge  and  personnel  skill  which  both  contribute  to  capabiliQr. 


i  A  General  Accounting  Office  Audit  Report,  specifically.  GAO/IMTEC-92-48  titled  as 
EMBEDDED  COMPUTER  SYSTEMS.  A  Significant  Software  Problem  On  C-17  Aimaft 
Software  Must  Be  Addressed.  Washington  DC:  The  General  Printing  Office:  May  1992 


I" 
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For  a  deuiM  diaiMuian  of  the 
Software  Bn(uieeriii|  Tooli 
tee  Voliane  1,  icctioo  9-3.5 


An  important  part  of  the  software  development  process  is  the 
application  of  computerized  management  tools,  Computer  Aided 
Software  Engineering  (CASE)  tools,  and  analysis  tools. 
Depending  on  the  particular  avionics  system  being  developed,  a 
broad  range  of  software  tools,  ranging  fimm  database  management 
to  software  design  tools  to  project  management  tools,  may  be 
required  to  support  the  effort. 

Software  tools  can  be  grouped  into  general  types  such  as 
management  tools,  development  tools,  and  laboratory  tools. 
Management  tools  include  tools  to  perform  planning,  scheduling, 
requirements  traceability,  configuration  control,  and 
documentation.  Development  tools  include  structured  analyzers, 
editors,  compilers,  code  generators,  debuggers,  and  emulators. 
Laboratory  tools  include  automated  testers,  data  manipulators, 
simulators,  and  real-time  non-inmisive  testers.  Many  of  the  tools 
required  for  developing  avionics  system  software  exist  today; 
however,  there  is  little  intention  between  and  among  these  tools. 
Three  tools  which  have  been  applied  successfully  at  NAVAIR  are 
Document  Director^'^,  Statemate'^^,  and  SESfWorkbench'^°^. 
Document  Director^’^  is  a  fiill-featured  requirements  management 
tool  that  combines  all  the  features  of  a  word  processor  widi  the 
power  of  a  database  management  system  to  prof^^e  for  the  traddng 
of  requirements  across  complex  specifications,  procedures,  tests 
plans,  and  other  documents.  Statemate'^”^  is  a  powerful,  graphical, 
system  specification/development  tool  for  the  validation  of 
complete,  consistent,  and  accurate  requirements. 
SES/WorkbencH^”^  is  a  multilevel  design  environment  for  system 
modeling  and  evaluation.  These  tools  are  being  used  or  are 
planned  for  use  on  the  following  programs:  ALFS,  AX,  CAINS, 
E-2C,  GPWS,  LAMPS  Mk3  Blk  n,  MH-SS,  and  T-45TS. 
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Software  Reuse 
Capability  Will 
Enhance  Systems 
Affordability  Only 
If  Matured 


Forawtc  infoonMiai  on 
■oflwan  mue,  nfer  to 
Volwe  1,  icctkaii  9-2.3.7. 
aad  9-3  J. 


F«  moic  iofoiiiiitioD  <ai  Otyeci- 
Oricniod  DMigii  (OOD)  nier  to 
VohuM  t,  Mdian 


>  Software  reuse  becomes  more  important  as  system 
functionality  moves  from  hardware  to  software. 

•  Hie  infrastructure  required  for  large  scale  software  reuse 
does  not  exist  today. 

•  Adoption  of  an  operating  systems  interface  promotes  reuse. 

•  Object-Oriented  Design  is  being  developed  to  support 
reuse. 

A  potential  major  cost  savings  could  be  realized  if  a  high 
percentage  of  software  is  reused  Software  reuse  is  currency 
practiced  in  an  ud  hoc  fashion,  and  there  is  no  tangible 
commitment  from  government  (or  incentive  to  industry)  to 
implement  and  apply  reusable  software. 

One  reason  for  the  lack  of  motivation  for  reuse  is  die  legal  issues  of 
responsibility  and  use.  Legal  issues  such  as  certification,  data 
li^ts,  repository  support,  pmormance  liabilities,  and  integration 
liabilities  are  all  tmlrowns  that  need  resolution  before  software 
developers  can  comfortably  embrace  sofnvare  reuse. 

Affordable  software  reuse  is  expected  to  become  more  and  more 
achievable  as  the  industry  transitions  to,  and  solves  some  of  the 
problems  associated  with,  Object-Oriented  Design  (OOD).  This 
new  design  methodology  is  a  major  departure  from  the  smictuied 
design  methodology  us^  to  develop  nc^y  all  programs  written  to 
date.  The  nuyor  benefits  of  (X>D  are: 

(1)  a  high  level  of  modularity, 

(2)  an  encapsulation  mechanism  to  support  information 
hiding, 

(3)  data  abstraction  to  support  creation  of  objects  that  refer  to 
a  single  basic  data  ty^  and  operation, 

(4)  a  classificadon  system  for  these  objects,  and 

(5)  an  inheritance  mechanism  that  provides  reusability  and 
extendibility. 

These  benefits  arc  most  desirable,  however,  the  standardization 
and  consistency  that  tiie  industry  achieves  with  this  new  design 
approach  will  determine  its  true  benefit  to  both  affordable  software 
development  and  reuse.  This  iransidon  will  not  be  either  quick  nor 
easy  because  Object-Oriented  Desigii  (OOD),  Object-Oriented 
Analysis  (OOA),  and  Object-Oriented  Programming  (OOP)  are 
difficult  to  mix  with  structmned  design,  amdysis.  and  progranuning. 
This  efieedvely  makes  it  an  "all  or  nodung"  corporate  comminnent 
adding  both  cost  and  risk  for  the  designer. 


Executive  ^SuInlnary 


One  highly  significant  fallout  of  the  evolving  natme  of  OOF  is  the 
debate  over  software  iangixu.^e  standard  selection  between  C-h-  and 
Ada.  The  basic  constructs  of  C++  support  a  geater  degree  of 
inheritance  and  polymorphism  than  Ada,  but  at  the  expense  of 
increased  complexity  and  the  real-time  operation  needed  for  many 
aircraft  applications.  Today,  these  problems  are  most  pronounced 
when  designing  large,  distributed  real-time  systems.  Ada  is 
attempting  to  accommodate  these  factors  because  DoD  has  a 
demanding  requirement  for  these  types  of  systems.^ 

While  the  infrastmeture  for  large  scale  sofuvare  reuse  is  not  fully 
available  today,  both  industry  and  the  government  are  trying  to 
hasten  its  evolution. 


Ada  Should  Remain 
DoD's  Software 
Language  Of  Choice 


Ad*  Imm  bMB  tvolvad  to  «ataR 
HtMlinacri  1—n.dawmwalad 

wrftwne  AtvrioiiinMi,  tgwud  for 
lail» ooMiilex lyMBf.  iMAdo 
drvolopmtat  pnooH  luaddfit 

ti>r*ki  iiid  hilmcM  vttAtA  fw 
itrftw«ni  nro«i«m.fi|tflf.dapaifln 
Md  twtgaion-betler  thm  ony 
other  higtxir  order  ImcuaKe. 


There  is  strong  indusny  support  for  specifying  Ada  for 
custom  applications,  systems  software,  and  any  &ge  scale 
avionics  systems. 

Industty  concurred  that  DoD's  use  of  a  standard  language 
is  needM  to  promote  mote  efficient  software  development 
and  reuse. 

Ada  is  appropriate  for  aircraft  because  it  accommodates  the 
large,  complex  systems  found  in  airamft. 

A  significant  segment  of  industry  recommended  that  DoD 
alter  policy  regairding  the  use  of  other  languages  in  roder  to 
optimize  the  opportunity  to  leverage  COTS  software 
I^oducts. 


norncm  fafamiMkn  <M  A(U  u 
•  Hifber  Order  Loiqpiaf  e 
(HOL)  refer  lo  Vohace  1, 
•ectiaa  +3.4. 


Industry  believes  that  standardizing  on  a  common  software 
language  promoies  nxne  efficient  softv^  development  and  reuse. 
Currently,  the  jnirrrary  alternative  to  Ada  under  consideration  by 
industry  is  C++.  Fig^  3  presents  our  teams  analysis  of  the  pros 
and  cons  for  both  languages.  While  diis  analysis  suggests  that  Ada 
should  be  the  language  of  choice  today,  DoD  needs  to 
continuously  assess  the  technical  trade-offs  and  requirements  as 
Ada  9X,  C++,  and  other  itigher  order  languages  (HOL)  continue  to 
maoue. 


^  Nielsen.  KjelL  Object-Oriented  Desim  with  Ada .  Maximizing  Reusability  for  Real-Time 
Systems.  New  Ycak,  NY:  Bantam  Books,  1992. 
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Hgure3:  Advantages  and  Disadvantages  of  Ada  and  C-h*. 


A  potential  problem  for  long  tmn  militaiy  use  of  Ada  is  that  little 
commercial  software  is  written  in  Ada.  While  the  Ada 
development  process  provides  the  attributes  listed  above,  as  well  as 
impormt  checks  and  balances  needed  for  software  program  error 
detection  and  correction,  it  is  initially  more  costly  to  write  than 
many  of  the  higher  order  languages  u;^  commercial  arolications. 
A  b^ance  must  be  struck  between  the  opportunities  anotded  by 
commercial  software  (especially  in  the  reidm  of  testing  and 
software  development  tools)  and  the  need  to  maintain  both 
software  and  software  processes  not  supported  by  commercial 
industry. 


Executive  Summary 


Joint  Ssrvico 
Acquisition  Makes 
Senk 


•  The  Joint  Integrated  Avionics  Working  Group  (JIAWG) 
baseline  provides  a  fhunework  for  a  modular  integrated 
avionics  architecture 

■  The  Navy-led  Standard  Hardware  and  Reliability  Program 
(SHARP)  is  leading  in  the  application  of  advanced 
technologies  to  standardize  modular  packaging  for  the 
military 

In  this  period  of  lean  budgets  it  is  important  that  the  Navy  and  the 
other  services  share  avionics  standaidizadon  approaches  in  (nxler  to 
broaden  our  applications  base  and  to  make  use  of  the  products  of 
research  and  standards  developed  by  all  of  the  services. 

Programs  such  as  JlAWG,  NGCR  and  SHARP  have  been  created 
to  establish,  in  their  own  way  and  by  different  approaches, 
architectural  standardization.  It  is  important  that  the  avionics 
community  utilize  these  programs  as  appropriate  to  contribute  to 
avionics  standardization.  For  in:itance,  JIAWG  standards  provide 
near-term  solutions  and  should  be  considered  and  used  where 
^)pUcable  to  meet  requirements. 

In  an  effort  to  provide  a  common  focus  to  tri-service  aviouics 
standardization  efforts  the  Joint  Aeronautical  Ckrmmanders  Group 
(JACG)  Engineering  Board  is  now  forming  an  Avionics 
Engineering  Sub-boara  (AESB).  The  Army,  Air  Force,  Navy, 
Defense  Logistics  Agency,  National  Aeronautics  and  Space 
Administration,  and  F^eral  Aviation  Administration,  will  be  co¬ 
equal  members  in  this  effort  to  create  more  compelling 
opportunities  for  avionics  standardization.  The  precepts  of  the 
AESB  will  be  to: 

(1)  Standardize  on  best  engineering  practices. 

(2)  Facilitate  the  joint  specification  development  process. 

(3)  Interface  with  industry  standards  bodies. 

(4)  Establish  common  standard/specification  verification/ 
qualification  and  configuration  control  methodology. 

(5)  Implementation  using  Systems  Engineering. 
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Technology  ’ 
Insertion  Can  Be 
Made  Affordable 


•  Effective  technology  insertion  can  provide  major  life-cycle 
cost  benehts. 

'•  •  An  open  systems  standards  approach  makes  technology 
insertion  easier. 

^  Industiy  wants  to  remove  obstacles  that  limit  innovation, 
creativity  and  mseition  of  newer  technology. 

-  DoD  can  best  achieve  technology  insertion  through 
standardized  architectural  requirements  and  use  of 
COTS/NDI. 

The  rate  of  new  generation  electronic  technology  advancement  is 
18  to  24  months.  .  Technologies  that  are  presently  in  development, 
but  not  yet  ready  for  exploitation,  are  considered  moderate  to  high 
risk  and  require  careful  planning  to  ensure  the  technology  will  be 
rerdy  for  insertion. 

Emerging  technology  is  considered  very  high  risk,  but  can  be 
tracked  to  determine  when  it  will  be  mature  enough  for  insertion. 
Open  systems  will  facilitate  technology  insertion  since  components 
and  modules  can  be  changied  almost  at  will  as  long  as  the  interfaces 
remain  compliant  with  the  standards.  The  use  or  an  open  systems 
standards-based  approach  allows  increased  numbers  of  technology 
sources,  the  ability  to  upgrade  without  redesign  and  provide 
flexibility  in  system  design  through  integration  capabiUty  and 
utilization  of  P^l/evolutionary  acquisition.  Systems  that  adopt 
popular  commercial  products  as  components  may  be  able  to  also 
leverage  tiieir  continuous  enhancement  This  allows  the  military  to 
avoid  the  high  risks  associated  with  productionizing  new 
technologies,  ^  using  state-of-the-art  appkeation  ready  products 
developed  at  the  commercial  consumer's  eiqiense. 


Executive  Summary 


Conclusions 


While  it  is  impossible  to  predict  what  avionics  architectures  will 
look  like  20  to  30  years  in  the  future,  it  is  possible  to  evaluate 
present-day  technology  trends  atid  select  those  technologies  that 
can  have  the  greatest  potential  impaa  on  future  avionics. 

Although  no  universal  architecture  will  satisfy  all  of  the 
requirements  of  naval  avionics  systems,  a  standards-based 
approach  to  systems  development  will  establish  a  basis  for 
consistenejr  among  platforms  that  provides  for  cost-effective 
technology  insertiem  aoA  performance  upgrade.  Endorsing  an  open 
system  standards-based  approach  allows  %e  Navy  to  move  into  the 
mainstream  of  modern  technology,  and  provides  a  broader 
industrial  base  to  support  our  systems  applications. 

The  Navy  should  limit  the  number  of  candidate  standards  to  just  a 
few,  so  that  diverse  requirements  can  be  met.  commonality 
achieved  and  cost  savings  realized.  Changes  should  be  made  so 
that  policy  regarding  architectural  choices  encourages  the  use  of 
COTS  and  I^I  hfudware  and  software,  and  encoivages  Navy 
participation  in  standards  develt^ment  groups.  Changes  in  the 
procui^ent  and  acquisition  process  (DAR  and  FAR  regidations) 
to  eliminate  stumbling  blocks  to  an  effective  systems  engineering 
integrated  product  team  approach  must  be  addressed. 

The  Navy  should  encourage  the  use  of  a  commercially  supported, 
open  systems  standards  based  approach  under  a  disciplined, 
systems  engineering  process. 

There  should  be  a  limited  number  of  standards  selected  from 
various  sources.  The  criteria  to  determine  the  preferred  standards 
should  be  part  of  the  systems  engineering  methodology. 

The  recommended  order  of  prec^ence  of  engineering  standards 
for  application  to  new  and  existing  systems,  within  the  systems 
engineering  process,  is: 

a)  Open  Systems  Standards  controlled  by  non-government 
standards  bodies 

b)  Widely-used  standards  under  Government  control 

c)  Standards  controlled  by  special  purpose  working  groups 

d)  Proprietary  standards  for  unique  interfaces 
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Recommendations 


Based  on  the  Hndings  of  this  study,  the  following  broad-based 
reconunendations  are  made. 


Use  an  Open 
Systems  Standaids- 
Based  Approach  to 
Avionics  Systems 
Development 


It  is  recommended  that  the  Navy  begin  the  transition  from  multiple 
avionics  design  architectures  that  are  unique  to  militai^  aircraft  to 
an  approach  that  capitalizes  on  open  system  opportunities.  It  was 
determined  that  no  universal  architecture  will  satisfy  the  diversity 
of  requirements  for  Navy  Avionics  systems.  But  just  as  a  single 
architecture  can  not  be  applied  efficiently,  a  Utmt  must  be  placed  on 
the  number  of  architectural  choices  to  achieve  reasonable 
standardization  and  commonality.  An  open  systems-based 
approach  provides  for  cost-effective  development  through  the  use 
of  widely-accepted  standards  with  broad  industry  support. 
Therefore,  transition  to  an  (pen  systems  standards-based  appi^h 
is  recommended  for  future  avionics  systems  develcpment  The  use 
of  open  standards  faciliutes  the  application  c>f  cOTS  and  NDl 
products  which  will  allow  NAVAIR  to  leverage  trends  in  the 
commercial  market  in  die  future. 


To  utilize  open  system  standards  fully,  it  is  recommended  that 
NAVAIR  be  an  active  paidcipant  in  the  standards  organizadons  tl^t 
are  respcmsiblc  for  applicable  open  system  standards.  This  activity 
wUl  become  familiar  with  the  detailed  technical  elements  of  these 
standards  ensure  that  naval  avionics  needs  are  considered  and 
incorporated  as  the  standards  are  dei'cloped. 

In  addidon,  it  is  recommended  that  the  Navy  establish  a  limited 
number  of  architectural  choices  through  a  managed  program  of 
technology  tracking,  standards  selection,  risk  assessment  and 
technical  t^e-off  s^es. 


Leverage  Jj  recommended  that  the  Navy  continue  to  promote  the  use  of 

Commercial  CX>TS  technology  and  products  in  military  systems  as  appropriate. 

Technology  and  Toward  this  end,  the  Navy  should  investigate  common  areas 
Products  between  commercial  and  military  avionics  systems  such  as 

communications,  navigation,  and  displays  sensep,  to  nanM  a  few, 
in  which  COTS  might  be  readily  applied  to  realize  immediate  cost 
savings. 

In  addition,  die  Navy  should  adopt  a  strategy  for  managing  cptimal 
CO^  use.  This  strategy  will  allow  conuniDrcial  imftware  tools  and 
development  systems  to  be  used,  where  appropriate,  lU  a  minimal 
cost  to  the  govenunent.  It  will  also  ensim  tiiat  COTS  is  not  the  de 
facto  choice,  but  that  ccmscious  selections  are  made  during  the 
systems  engineering  process. 


18 


iixccuuvc  aiuiiiiuu  y 


Support  Joint 
Service  Programs 


It  is  recommended  that  the  Navy  aggressively  and  actively 
participate  in  joint  service  programs.  Qwidinated  DoD  efforts  will 
allow  more  efficient  management  of  scarce  DoD  resources  and 
focus  industry's  effoits  on  consolidated  military  requirements. 
Joint  service  programs  allow  the  Navy  to  take  advantage  of  other 
service  efforts  and  to  share  the  cost  of  developments.  Additional 
cost  advantages  can  be  derived  from  larger  production  buys, 
shared  maintenance  facilities,  and  common  support  systems. 
Further,  the  participating  services  can  use  each  others'  research  in 
defining  and  developing  their  systems.  The  goal  for  these  efforts 
should  be  equipment  and  software  commonality  between  and 
among  platforms,  otherwise  the  advantages  are  significantly 
reduc^. 


It  is  recommended  that  Navy  continue  to  develop  the  tri-service 
Avionics  Engineering  Sub-board  (AESB)  of  the  Joint  Aeronautical 
Commanders  Group  (JACG)  En^neering  Board.  Joint  service 
cooperation  and  resource  contributions  will  be  required  to  increase 
weapon  systems  affordability  by  developing  a  higher  level  of 
commondity  in  avionics  systems  and  subsystems.  This 
commonality  may  be  achieved  through  the  management  of  avionics 
architectures,  processes,  standards,  and  specifications. 

It  is  recommended  that  the  Navy  continue  its  support  to  Joint  and 
Tri-Service  efforts  such  as  JIAWG,  NGCI^  MASA  and  SHARR 
It  is  important  that  the  Navy,  together  with  the  other  Services, 
share  avionics  standardization  approaches  to  broaden  our 
applications  base  and  utilize  the  research  and  standards  developed 
by  all  the  services  when  applicable. 


Invest  A 
Software 
Development 
Infrastructure  Now 
To  Establish  Long 
Term  Software 
Affordability 


It  is  recommended  that  more  corporate  attention  ixus  on  software 
affordabilit}'.  Applying  systems  en|;ineering  principles  to  software 
development  and  its  management  is  fundaimntal.  Software  cost 
management  is  also  closely  linked  to  effective  requirements 
analysis  since  stabilizing  requirements  early  in  the  jnocess  esn 
provide  extensive  cost  savings.  For  example,  process  analysis 
using  software  metrics  and  corporate  commitment  to  correct 
identified  deficiencies  will  pay  dividends  in  achieving  quality,  cost- 
effective  software.  It  is  recommended  that  efforts  should  be  taken 
to  track  the  viability  of  commercial  software  languages  for 
opportunities.  It  is  also  recommended  that  software  reuse  be 
encouraged  and  supported  as  a  cooperative  effort  between  the 
government  and  industry. 
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Ensure  that  a 
Rigorous  Systems 
Engineering 
Approach  is  Used 


It  is  recommended  that  the  Navy  establish  a  formal  system 
engineering  approach  to  guide  architectural  choice,  engineering 
standards  selection,  and  implementation  and  integration  of  cost- 
effective  technological  solutions  to  naval  avionics  problems. 
Systems  Engineering  is  regarded  with  such  special  significance  by 
the  review  team  that  a  complete  volume  of  this  report.  Volume  2, 
has  been  devoted  to  the  systems  en^eering  process.  The  systems 
engineering  approach  will  synthesize  effective  avionics  systems 
solutions  utilizing  COTS  where  appropriate,  while  satisfying  all 
constraints  of  cost,  schedule  and  pmormance.  The  application  of 
COTS  and  NDI  {m^ucts,  which  includes  joint  service  program 
products,  into  avionics  systems  provides  more  affordable  systems. 
However,  leveraging  commercially-based  and  existing  military 
products  places  a  significant  burden  on  systems  engineering  and 
must  be  managed. 

To  assist  with  both  the  management  and  implementadon  of  systems 
engineering,  an  investment  will  be  needed  in  modeling  and 
development  software  tools.  While  we  should  leverage  the  tools 
used  industry,  investment  in  state  of  the  art  tools  will  greatly 
increase  productivi^  and  cost  savings  if  we  aie  selective  and 
properly  train  for  theu  use. 

A  systems  engineering  approach  is  already  in  place  in  the  naval 
avionics  community.  It  is  recommended  that  the  systems 
engineering  process  of  MIL-STD-  499B  be  tailored  for  avionics. 
In  addition,  it  is  recommended  that  the  benefits  of  closer  integration 
with  industry  throughout  the  systems  engineering  process  be 
examined,  especially  for  large  scale  development  or  upgrade 
programs.  It  is  further  recommended  that  to  manage  investment  of 
high-cost  technology  integration,  a  systemadc  method  of  tracking 
technology  and  standardization  be  est^lished. 
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1-0  A  QUESTION  OF  SCOPE:  WHAT  IS  AVIONICS? 

Avionics  is  commonly  understood  to  be  electronics  used  aboard  aircraft,  i.e.,  as  an 
aircraft  subsystem.  But  for  purposes  of  this  study  the  range  of  the  common  definition 
was  more  focused.  For  example,  because  of  the  traditional  way  of  partitioning  aircraft 
subsystems,  the  flight  control  computers  and  related  electronics  are  normally  under  the 
cognizance  of  the  aeronautical  engineering  divisions,  even  though  they  fit  the  broad 
definition  of  "avionics."  For  purposes  of  this  report,  therefore,  avionics  means  all  on¬ 
board  aircraft  electronics  except  the  flight  and  engine  control  electronics.  Subdivisions  of 
the  avionics  category  include  flight  avionics  (e.g.,  common  with  all  aircraft,  i.c., 
navigation,  communications),  tactical  sensors  (radar  and  eleccro-optical),  and  computer 
resources.  This  subdivision  is  somewhat  arbitral,  but  nonetheless  useful. 

One  of  the  pu^sc:.  o  this  study  is  to  identify  areas  and  meajis  of  cost  savings 
with  respect  to  avionics.  When  the  different  sub  categories  of  avionics  systems  are 
examined,  it  becomes  apparent  that  the  two  main  cost  (Mvers  are  tactical  sensors  (e.g., 
radar  and  electro-optics)  and  computer  resources.  The  sensors  cost  factors  are 
considerably  higher  than  the  computer  resources  cost  factors  (even  though  both  are 
large),  so  by  the  normal  rules  of  Pareto  analysis,  a  discipline  used  extensive  oy 
practitioners  of  Total  Quality  Leadership,  one  mi^t  assume  that  the  Advanced  Avionics 
Architecture  and  Technology  Review  Team(AAART)  would  put  the  main  emphasis  on 
tactical  sensors  rather  than  computer  resources.  However,  after  close  analysis  it  was  seen 
that  much  of  the  cost  burden  of  tactical  sensors  is  due  to  computer  hardware  and  software 
embedded  within  these  sensor  subsystems,  so  the  two  main  problem  areas  overlap. 
Therefore,  paying  close  attention  to  computer  resources  problems  deals  with  both  majonr 
cost  drivers  in  an  effective  way.  In  addition,  among  all  Navy  aircraft  there  is  a  much 
broader  based  common  area  of  technology  in  the  computer  resources  (both  mission 
computers  and  embedded  subsystem  computers)  than  in  the  non-computer  areas  of  sensor 
technology.  There  is  also  the  ket  that  computer  technology  is  now  used  extensively  in 
non  sensor  avionics  subsystems.  It  was  determined  that  a  major  contribution  to  Navy 
avionics  could  be  made  by  addressing  the  study  primarily  to  the  computer  resources,  but 
with  some  attention  paid  to  non  computer  tactical  sensor  technology.  Avionics  that  do  not 
fit  into  these  categories  are  important,  but  are  not  discussed  herein  because  their  overall 
effect  on  possible  cost  reductions  is  low  compared  with  computer  and  sensor 
technologies. 
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2-0  WHY  STUDY  SYSTEMS  ARCHITECTURE? 


This  study  focused  on  avionics  systems  architectures  because  the  fundamental 
architecture  underlying  any  system  predetermines  initial  development  costs,  future 
flexibility  to  meet  changing  requirements,  and  the  ease  with  which  new  technology  can 
be  incorporated  into  the  system.  Architecture  also  detennines  both  the  degree  to  which 
the  Navy  can  leverage  commercial  research  and  development  funding,  and  the  level  at 
which  the  products  of  commercial  R&D  is  useful  to  the  Navy.  Certain  architectmes  are 
inherently  more  amenable  to  the  use  of  Non-Developmental  Items  (NDl)  and  ccnunercial 
off  the  shelf  (COTS)  hardware  and  software  than  others,  so  it  becomes  necessary  to 
understand  the  implications  of  architectures  on  our  future  capabilities. 

Major  architectural  decisions  tend  to  be  made  early  in  the  design  of  a  system,  and 
those  decisions  —  once  firm  —  considerably  reduce  the  ability  to  change  course  in  the 
future.  In  the  present  state  of  affairs,  for  example,  if  the  wrong  architecture  is  selected 
very  early  in  a  program,  then  the  ability  to  effect  fundamental  design  changes  is  reduced, 
even  as  early  as  the  Preliminary  Design  Review  (PDR).  As  a  result,  new  technologies  and 
commercial  R&D  cannot  easily  be  exploited  for  Navy  systems  if  the  wrong  decision.s  are 
made  early  in  the  process.  Nor  can  new  or  evolving  threats  be  met  without  either  veiy 
costly  and  dme  consuming  redesign  of  an  old  system,  or  procurement  of  an  entinely  new 
system. 


Selecting  viable  aichitectures,  and  acquiring  sufficient  useful  infonm.tion  about 
them,  substandally  improves  our  ability  to  respond  to  a  dynamic  environment,  even  in  the 
face  of  hirfi  complexipr.  The  greatest  leverage  on  a  system's  life  cycle  is  found  in  the 
early  architectural  decisions,  and  is  maintain^  by  keeping  as  many  options  as  possible 
open  to  the  latest  possible  time. 

Tiiis  report  describes  many  of  the  technologies  available  to  designers  of  Naval  air 
weapons  systems.  Understanding  these  technologies  aids  the  systems  architect  in  creating 
designs  that  allow  the  exploitation  of  emerging  technologies  even  in  an  environment  of 
reduced  funding. 
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3-0  SYSTEMS  AND  SYSTEMS  ARCHITECTURE 


Modern  weapons  systems,  of  which  avionics  represents  a  major  sub  categoty,  arc 
very  complex  compared  to  systems  of  just  a  decade  or  two  ago.  As  a  result,  design  of 
systems  has  become  much  more  complex  than  before.  It  is  well  recognized  that  the 
problems  of  designing  very  complex  systems  grows  much  faster  than  the  complexity  of 
the  system  itself.  Therefore,  small  changes  in  system  complexity  can  create  much  larger 
changes  in  the  problems  associated  with  designing  and  fielding  the  system.  Before  the 
problems  of  designing  and  managing  complex  systems  can  be  addressed,  some 
dcfmitions  must  be  understood. 


3-1  Systems 

According  to  Webster's  New  Collegiate  Dictionary  ,  a  system  is  "...a  regularly 
interacting  cr  interdependent  group  ...forming  a  unified  whole,"  or  "...[a  body  of  parts] 
considered  as  a  functional  whole  [in  a]  harmonious  arrangement  or  pattern  [emphasis 
added]."  Ret-htin  (1991)  goes  further  and  points  out  that  a  system  possesses  what  are 
called  emeigent  properties ,  i.e.,  properties  or  attributes  that  are  not  evident  by  examining 
the  component  elements  apart  from  the  system.  Checkland  (1981)  asserts  that  the  very 
concept  of  'system'  deals  with  these  emergent  properties  rather  than  the  properties  of  the 
components.  The  properties  of  a  human  body,  for  example,  cannot  be  fully  ascertained 
from  understanding  the  properties  of  the  various  parts  of  the  body.  When  a  system  is 
broken  ap?irt,  emergent  properties  disappear.  For  example,  cutting  an  adult  human  body 
into  two  equal  pieces  does  not  result  in  a  pair  of  twin  children,  but  rather  a  dead  adult. 
The  naval  airemft  and  its  avionics  suite  form  a  system  that  cannot  be  understood  apart 
from  the  aggregate.  At  lower  levels,  the  avionics  suite  forms  a  system,  which  is  in  turn 
maijc  of  subsystems,  all  of  which  interact  in  such  a  way  as  to  form  a  whole  that  is  greater 
than  tlie  sum  of  its  pans  (i.e.,  sj^nergism).  If  an  agpegation  fails  the  tests  of 
interconnectedness  and  synergy,  then  it  is  not  a  system.  But  if  it  passes  these  tests,  then  it 
is  a  system  and  must  be  dealt  with  in  the  whole,  as  a  system,  and  not  simply  as  a 
collection  of  parts.  In  the  past,  we  often  dealt  with  systems  isolated  from  their  larger 
contcxt...a  luxury  that  we  can  no  longer  afford.  As  complexity  grows,  and  resources 
dwindle,  the  old  way  of  doing  things  becomes  untenable. 


3-2  Standards 

A  tenn  used  a  lot  in  discussions  of  avionics  architectures  is  standards.  A 
principal  finding  of  the  AART  was  that  the  most  viable  methodology  for  acquisition  of 
naval  avionics  is  a  well-defined  standards-based  approach  modulated  by  a  rigorous 
systems  engineering  process.  In  the  general  sense,  a  standard  is  a  written  "...means  of 
determining  what  a  thing  should  be..."  that  is  regularly  and  widely  available,  accepted  and 
used.  Related  words  include  criterion,  gauge,  yardstick  and  touchstone.  A  standard  is  a 
vTitten  document  that  can  be  used  to  compare  a  thing  against.  In  the  more  specific  sense, 
a  standard  is  a  document  produced  by  an  authority  and  widely  promulgated.  Private 
standards  (company  proprietary),  government  standards,  and  industry  standards  can 
qualify,  but  in  the  limited  sense  used  in  this  report  it  is  widely  used  industry  consensus 
standards  that  arc  meant.  These  standards  arc  put  together  by  groups  that  contain 
representation  from  a  large  segment  of  the  potential  user  group.  Such  standards  are 
typically  given  a  number  and  quoted  as  such  (e.g.,  IEEE-896,  ANSI  91,  ISO-9000,  etc.) 
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3-3  Architecture 

The  concept  of  archi'^cture  ,  as  it  applies  to  an  avionics  system,  is  related  to  the 
same  concept  in  building  construction.  TTic  word  architecture  incorporates  the  complete 
set  of  factors  that  contribute  to  making  the  avionics  suite  into  a  system  that  works  as  a 
unified  functional  whole  to  accomplish  the  mission  of  the  aircraft. 

Avionics  architeenue,  like  its  building  counterpart,  is  hierarchical  (i.e.,  layered) 
and  multifaceted.  A  glimpse  of  some  of  these  aspects  of  architecture  can  be  seen  in  a  list 
of  typical  attributes  of  an  avionics  architecture: 

Communications: 

•  Information  flow  and  communications  pathways  (e.g.,  "wiring  diagram") 

•  Backplane  bus  or  buses  used 

•  Interfaces  within  the  system 

•  Interfaces  to  the  "outside  world" 

Conmutarions: 

•  Speed,  throughput,  latency,  and  redundancy  of  computer  processors  and  data 
communicadons 

•  Processors  used  in  various  functions  (common  or  multiple  types) 

•  Type,  location,  size  and  arrangement  of  memory  devices 

•  Software  used 

OrEanizatioa; 

•  Type  and  arrangement  of  sensors 

•  Type  and  arrangement  of  mission  avionics 

•  Style  of  arrangement  of  major  components  (e.g.,  federated,  distributed, 
centralized,  etc.) 

•  Number  and  location  of  computer  processors 

•  Physical  arrangement  of  hardware  in  the  system 

The  concept  of  "architecture"  incorporates  the  complete  range  of  factors  that 
make  the  system  perform  as  a  functional  whole.  Avionics  architectures  describe  the 
form,  structure  and  interrelationships  between  the  avionics  system  and  the  aircraft,  ai^ 
amongst  the  elements  of  the  avionics  system  itself.  The  selection  of  backplane  bus  vdthin 
the  computers,  the  types  of  Electro-Optic  (EO)  and  radar  sensors  used,  and  the  sydtehes 
used  on  the  control  panel  are  all  part  of  "architecture.”  Because  the  task  of  architecture 
derinition  is  hierarclucal  however,  different  aspects  of  the  architecture  are  apportioned  to 
different  tasks  in  the  process  of  creating  the  system.  For  cxunple,  the  selection  of 
switches  for  the  control  panel  is  properly  delegated  to  a  detail  designer,  and  not  the 
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system  engineering  architect.  The  pardUorung  of  functions,  with  due  regaid  to  which 
layer  is  appropriate,  is  a  systems  engineering  task  that  must  be  performed  very  early  in 
the  process. 


3-4  Types  of  4vionic$  Architectures 

In  this  report;  the  terms  "architecture"  is  used  moictly  for  the  higher  levels  of  the 
hierarchy  tiers  where  functions  arc  partitioned  and  the  structure  of  their  respective 
interconnections  can  be  dealt  with  most  effectively. 

Several  different  generic  types  of  avionics  architecture  have  evolved  over  the 
years,  and  these  are  described  in  the  sections  below.  The  categories  overlap,  and  have 
fuz^  boundaries  between  tliem,  and  should  be  taken  as  general  guidelines  only  when  the 
various  types  of  architecture  are  discussed. 


3-4.1  Independent  Architecture 

The  independent  architecture  is  tite  oldest  avionics  architecture,  and  dates  from 
the  late  1920s  when  radios  were  first  installed  on  aircraft  In  this  type  of  system,  all 
subsystems  are  completely  independent  except  for  sharing  a  common  j^wer  source  and 
common  environmental  control  system.  A  nii^  or  radio,  for  example,  could  be  installed 
Qbo^  an  early  World  War  n  era  aircraft  with  only  minimal  concern  for  other  avionics 
devices  on  board.  These  systems  were  common  into  the  early  19'60s,  but  are  now 
regarded  as  obsolete. 


3-4  Federated  Architectures 

Indracndent  architectures  were  replaced  with  federated  architectures  starting  in 
the  late  1940s,  but  accelerating  in  1960s.  The  key  enabling  factor  in  the  rapid  ascenchmey 
of  the  federated  architectures  in  the  1960s  was  the  rise  of  computers  and  data 
communications  technologies.  In  the  iterated  system,  overall  control  and  a  certain 
amount  of  functionality  of  each  avionics  subsy3jLt;^m,  is  delegated  to  a  central  mission 
computer.  As  computer  capability  increased,  so  did  the  percentage  of  total  functionality 
app^oned  to  software.  Subsystems  (e.g.,  radar,  navigation,  communications,  etc.)  talk 
to  each  other  over  a  standardized  data  bus  (e.g.,  M1L-STD-15S3)  using  a  commep  data 
format.  The  data  bus  might  be  local  (within  a  subsystem),  dedicated  (between 
subsystems)  or  global  (to  all  —  or  a  major  block  of  —  airci^  subsystems). 

An  advantage  of  the  federated  system,  over  the  older  independent  ^stem,  is  that  it 
permits  better  interaction  of  several  avionics  subsystems  to  form  a  syneigistic  whole.  Fbr 
exan^le,  radar  and  navigation  systems  can  interact  with  each  other  to  provide  updates  to 
positional  knowledge  in  the  navigational  system  and  better  ground  maps  for  the  radar. 
Both  systems  are  i^e  better  because  they  communicate  with  each  other  through  the 
software  of  the  central  mission  computer.  Similarly,  new  tactical  advantages  emerge 
when  radar,  E-0  and  Electronic  Warfare  (EW)  sensors  interact  in  a  cohoent  manner. 

Federated  architecture  does  not  imply  that  the  subsystems  do  not  have  any 
computer  processing  of  their  own,  but  rather  that  central  coordination  and  control  is 
delegated  to  the  mission  computer.  Forward  looking  infrared  (FLIR)  £-0  and  radar 
subsystems,  for  example,  might  each  possess  very  powerful  signal  processing  computers 
and  data  computers  within  the  subsystem,  but  control,  display  and  interactions  with  other 
systems  is  bandied  by  the  central  mission  computer. 
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Between  the  19^s  and  the  1980s  aircraft  design  became  firmly  entrenched  in  the 
federated  model,  and  the  F/A-18  provides  a  very  good  example  of  an  advanced  federated 
avionics  system. 


3>4  J  Integrated  Architectures 

An  integrated  architecture  is  one  in  which  all,  or  nearly  all,  cf  the  elccttxinics 
elements  of  the  avionics  system  are  packaged  in  standard  modules,  and  installed  in 
several  (but  very  few)  co-locatcd  common  racks.  Because  the  computer  resources  of  a 
modem  avionics  suite  are  so  numerous,  the  term  "intemted”  could  also  mean  a  system  in 
which  the  computing  elements,  and  supimrting  modules,  are  co-located  in  a  common 
rack.  The  Joint  Integrated  Avionics  Working  Group  (JIAWG)  architecture  is  an  example 
of  this  concept 

In  other  cases,  elements  such  as  radio  finequency  (RF)  modules,  for  use  in  radar, 
electromc  warfare,  communications  and  navigation  systems  could  also  be  integrated  into 
a  single  rack  structure.  The  Integrated  Communications,  Navigation,  Identification 
Avionics  (ICNIA)  system  and  the  INtegrated  Electronic  Warfare  System  (INEWS)  are 
examples  of  this  class  of  integrated  system.  Problems  of  interface  connections  and 
electromagnetic  interference  (EMI)  witiiin  the  racks  must  still  be  solved,  however. 


34.4  Distributed  Architectures 

A  distributed  architecture  resembles  an  integrated  architecture  in  that  elements  of 
the  system  are  collocated  in  racks  or  cabinets.  It  also  resembles  a  federated  system  in  that 
a  considerable  amouu;  of  digital  signal  processing  is  done  m  the  subsystems.  In  a 
distributed  system,  major  elements  of  the  digital  signals  processing  are  located  at  the 
sensor  or  other  subsystem  site.  For  example,  a  radar  system  may  have  substantial  signal 
pn^rocessing  capability,  located  with  the  radar  receiver,  at  or  near  the  antenna  site.  The 
mam  signals  processing  function  is  performed  in  the  central  computer,  as  in  the  integrated 
system,  but  preprocessing  eases  the  chore.  Such  systems  have  the  potential  for  off¬ 
loading  traffic  on  aircraft  data  buses,  and  reducing  the  woridoad  of  the  central  processors. 
In  addition,  special  requirements  of  a  system  can  be  locally  accommodated  without  being 
imposed  on  thi!r  entire  system. 

Some  advocates  assert  that  the  distributed  architecture  is  more  robust  than  the 
integrated  architecture  because  combat  damage  to  a  single  site  cannot  incapacitate  all 
systems.  Others  believe  that  proper  design,  with  built-in  redundancy,  can  overcome  this 
problem  with  integrated  architectures.  It  is  not  clear  that  the  combat  robusmess  of 
distributed  systems  is  better  than  that  of  integrated  systems,  and  the  arguments  of  the 
advocates  are  as  yet  unconvincing. 

A  system  can  still  be  regarded  as  a  distributed  architecture  if  it  uses  common  RF 
signal  and  wave  form  source.*,  located  at  a  central  site.  At  some  level,  however,  the 
boundaries  between  a  sophisticated  federated  architecture,  the  distributed  architecture  and 
the  integrated  architecture  begin  to  blur.  The  location  of  those  boundaries,  and  the  degree 
to  which  a  system  is  either  distributed  or  integrated,  is  the  proper  subject  of  rigorous 
systems  engineering  analysis,  and  may  vary  wi£  the  overall  system  design,  the  inherited 
legacy  of  earlier  subsystems  in  the  same  system,  available  technology  and  cost 
constraints. 
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3-5  Architecture  Standardization 

The  rising  complexity  and  cost  of  avionics  products  has  increased  the  need  for  1) 
the  systems  developer  to  leverage  the  work  of  others  where  ever  possible,  and  2)  the 
product  vendor  to  have  access  to  sufficient  market  share  to  amortize  development  and 
production  design  cost  over  an  acceptable  number  of  units.  Consequently,  an  important 
issue  that  must  be  considered  when  designing  a  new  or  substantially  modified  a\'ionics 
system  or  subsystem  is  whether  to  make  it  a  closed  system  architecture  (CSA)  or  an 
open  system  architecture  (OS A),  There  is  a  lot  of  discussion  in  both  commercial  and 
military  sectors  over  open  systems  architectures  versus  closed  systems  architectures. 
AART  believes  that  the  OSA  approach  should  be  considered  fust  for  most  applications, 
but  not  at  the  automatic  exclusion  of  CSA  approaches  if  the  true  requirements  u-e 
supported  only  in  a  CSA  design.  In  the  sections  below  these  terms  are  discussed  in  detail. 


3-5.1  Closed  Systems  Architecture 

The  term  closed  system  architecture  (CSA)  merely  places  a  label  on  an  older 
concept  that  did  not  need  a  label  until  open  systems  became  popular.  A  CIS  A  implies  that 
the  standards  and  specifications  for  the  system  are  not  open  for  use  by  anyone  who  wants 
to  use  them.  Closed  systems  tend  to  be  made  to  proprietary  standards  that  are  not  in  the 
public  domain,  so  as  a  result  the  government  does  not  obtain  the  information  needed  for 
complete  supj^.  For  example,  a  computer  backplane  bus,  and  the  software  opmting 
system  used  by  the  computer,  may  be  the  private  property  of  the  contractor  supplying  the 
product.  While  one  can  argue  that  Government  contracts  impute  all  rights  to  the 
Government,  that  issue  is  frequently  in  contention,  and  the  Government  frequently  loses 
the  battle.  Thus,  the  CSA  limits  the  ability  of  the  Government  to  use  any  source  other 
than  the  original  contractor. 

It  is  possible  to  optimize  a  "point  solution"  closed  system  design  for  the  intended 
purpose.  While  that  advantage  is  sometimes  lest  in  open  systems  designs.  No  regard 
need  be  paid  to  industry-wide  consensus  standards  committees  for  needed  changes  to  a 
closed  system.  On  the  other  hand,  that  freedom  is  purchased  at  the  cost  of  effectively 
locking  in  the  original  contractor,  and  history  shows  that  approach  is  very  costly. 
Optimi^  point  solutions  are  usually  difficult  and  expensive  to  change. 


3-5JS  Open  Systems  Architectures 

An  open  system  is  one  that  is  sufficiently  derined  to  provide  for  expansion, 
upgrading  or  functional  reconfiguration  through  the  incorporation  of  replaceable  modular 
elements.  The  concept  applies  to  both  hardware  and  software.  An  example  of  an  open 
system  is  the  desktop  computer  in  which  the  hardware  and  software  can  be  configured  as 
a  word  processor,  a  data  or  signals  acquisition  system,  or  a  graphics  processor  depending 
on  the  plug-in  caids  and  software  progranos  inst^ed. 

An  open  system  must  have  all  aspects  of  the  system  interfaces  so  well  defined, 
preferably  in  public  domain  standards,  that  independent  designers  of  subsystems  or 
modules  can  do  their  work  without  close  coordination  with  each  other.  Under  the  ideal 
situation,  a  product  can  be  installed  in  an  open  system  with  only  minimal  integration.  The 
integration  normally  required  when  integrating  plug-in  boards  into  a  desktop  computer, 
for  example,  typically  involves  redirecting  conflicting  communication  port  assignments, 
interrupt  line  assignments,  and  the  memory  locations  sought  by  on-boaid  memory.  As 
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long  as  one  dcKis  not  auempt  to  install  tv/o  like-function  boards  into  the  same  system,  the 
effort  is  ostensibly  trouble  free. 

The  standards  and  specifications  governing  the  open  system  must  be  non 
proprietary,  widely  used,  and  well  recognized  tluoughout  industry.  In  most  cases,  an  open 
system  will  be  compatible  with  one  or  more  consensus  standards  promulgated  by 
industry-wide  organizations  such  as  the  Institute  of  Electrical  and  Electronic  Engineers 
(IEEE),  the  Society  of  Automotive  Engineers  (SAE),  American  National  Standards 
Institute  (ANSI),  the  International  Elcctro-tcchnical  Conmussicn  (lEC)  and  the 
International  Standards  Organization  (ISO).  Key  elements  defining  open  systems 
standards  include  a  formal  control  mechanism  involving  due  deliberation  of  Lnterested 
parties  for  changes,  and  an  effective  configuration  management  system. 

Some  people  maintain  that  an  "open"  standard  must  be  in  the  public  domain  (i.e., 
non  proprietary)  so  that  it  can  be  used  without  either  permission  or  payment  of  license 
fees.  In  general,  this  position  seems  reasonable  because  proprictaty  standards  may  give 
the  proprietor  both  unacceptable  control  over  a  design,  and  an  unfair  competitive  business 
advantage  when  competing  with  non  proprietors  for  Navy  contracts.  But  the  ISO  regards 
a  standard  as  "open"  even  if  license  fees  axe  lequiicd,  provided  that  the  fees  are  moderate 
and  licensing  is  not  discriminatory.  Thus,  degrees  of  openness  may  be  encountered, 
especially  in  regards  to  international  commercial  consensus  standards. 


3>5  J  U.S.  Government  Standards  and  Openness 

Most  U.S.  Government  standards  and  specificatiains  are  not  usually  open  in  the 
sense  of  being  in  widespread  use,  but  that  is  not  universally  the  case.  If  a  standard  is 
relatively  stable,  conriguration  controlled,  and  has  achieved  widespread  recognition,  then 
it  may  be  construed  as  being  open.  For  example,  MIL-STD-1553  defines  a  data  bus  for 
use  between  systems  or  boxes  in  a  military  avionics  system.  It  is  no' t  pen  in  the  normal 
sense  of  the  word,  because  its  use  is  relatively  narrow  (military  aircraft,  witii  only  a  few 
commercial  applications).  It  becomes  quasi-open,  even  though  not  an  industry  consensus 
standard,  because  a  large  number  of  commercial  chip  providers  make  1553  transceiver 
devices  for  incorporation  into  other  products.  Thus,  any  user,  nnlitary  or  not,  can  use  the 
MIL-STD-1553  bus  without  needing  permission  from  a  proprietor. 

Although  the  Joint  Integrated  Avionics  Working  Group  (JIAWG)  standards  can 
evolve  into  an  open,  or  at  least  quasi-open  standards,  at  present  its  general  unavailability 
and  lack  of  widespr^  use  does  not  suggest  openness  according  to  the  above  definition. 
It  is  claimed  that  JIAWG  will  evolve  to  an  open  standard  by  1996. 


3-5.4  Advantages  and  Disadvantages  of  Open  Systems  Architectures 

The  use  of  an  open  systems  architecture  (OS A)  makes  it  possible  to  n^e 
maximum  use  of  multiple  commercial  sources  of  both  hardware  and  software  at  mininud 
cost.  An  OSA  is  a  method  for  making  the  commercial-off-the-shelf  (COTS)  concept 
work.  In  addition,  system  design  turnaround  times  can  become  much  shorter  when  good 
open  systems  architectures  are  specified  because  of  the  potential  availatnlity  of  hardware 
and  software  products  on  the  commercial  market.  There  is  also  the  fact  that  key  interface 
problems  are  solved  by  the  specification  of  the  particular  OSA  selected.  A  good  OSA 
permits  rapid  upgrading  and  prototyping  of  system  enhancements  once  the  system  has 
been  field^. 
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Computer  based  modeling  and  simulation  of  systems  is  widely  accepted  as  a 
powerful  systems  engineering  tool.  Some  see  these  related  tools  as  twing  absolutely 
essential  in  the  design  of  complex  systems.  They  share  the  attribute  of  blowing  the 
systems  designer  to  "test  drive"  different  architectures  and  configurations  on  a  computer 
prior  to  committing  large  amounts  of  resources  and  time  to  a  design.  I^blems  can  be 
identified  and  either  solved  or  evaluated  as  to  seriousness  prior  to  any  final  commitment. 
An  advantage  of  the  open  systems  approach  is  that  an  OSA  is  easily  modeled,  and  the 
model  can  remain  stable  as  long  as  the  underlying  standards  that  define  the  OSA  are  also 
stable.  In  addition,  there  are  often  multiple  models  of  any  given  OSA  available,  so  the 
systems  designer  can  chose  from  the  many.  While  each  model  may  reflect  different 
assumptions,  a  general  sense  of  the  design  integrity  can  emerge  from  their  use.  The  use  of 
standaixlized  systems  noodels  allows  quick,  low  cost  comparisons  to  be  made  on  "before" 
and  "after"  versions  of  the  system  whenever  changes  are  proposed.  If  the  system  were  a 
closed  point  solution  design,  on  the  other  hand,  the  progr^  manager  will  be  faced  with 
the  cost  of  creating  and  validating  a  model  for  the  specific  system,  and  that  task  may 
prove  prohibitively  expensive. 

Despite  its  strengths,  the  OSA  concept  is  not  a  panacea  to  all  problems  involved 
in  avionics  systems  development.  While  the  advantages  of  OSAs  are  substantial,  and  an 
argument  can  be  made  that  OSA  is  the  way  the  Navy  should  build  most  future  systems, 
there  are  some  disadvantages  and  problems  that  need  to  be  addressed. 

One  major  problem  is  that  products  are  often  touted  as  meeting  the  specification 
on  which  an  OSA  design  is  based,  only  to  find  out  later  that  certain  Unctions,  memory 
locations  or  connector  pins  that  are  left  available  for  the  user's  defrtution  in  the  standard 
are  used  differently  by  different  vendors. 

Configuration  control  over  modules  will  usually  be  lacking,  so  a  user  will  find 
that  a  system  element  that  worked  well  with  the  rest  of  the  system  becomes  incompatible 
because  of  unilateral  changes  made  to  the  user  definable  portions  of  the  system. 

Another  disadvantage  is  that  OSA  solutions  are  usually  not  optimum  solutions. 
All  OSAs  involve  compromises  of  one  sort  or  another,  for  that  is  the  nature  of  consensus 
standards,  and  these  may  work  together  to  make  a  solution  sub  optimum.  The  question 
for  the  system  designer  is  whether  or  not  the  solutions  allowed  by  the  OSA  are  acceptable 
-  as  opposed  to  optimum  -  solutions.  If  they  are  not,  then  the  systems  designer  may  well 
want  to  consider  a  point  design  solution.  Again,  a  rigorous  systems  engineering  process  is 
needed  to  discern  truth. 

Some  opponents  of  open  systems  architecture  assert  that  the  very  nature  of  OSAs 
requires  the  Navy  to  accept  of  the  package,  or  none  of  it  What  this  approach  means  is 
that  bugs,  errors,  or  glitches  lurking  undetect^  in  the  hardware  or  software  -  which  was 
supplied  as  compliant  to  the  standard  -  can  cause  unforeseen  problems  in  the  field  (some 
of  which  may  take  years  to  surface).  Because  commercial  vendors  may  not  test  all 
possible  conditions  as  rigorously  as  military  systems  are  tested,  problems  that  are  not 
critical  to  civilian  users  may  not  surface  until  the  system  is  subjected  to  military 
environments.  No  one  warrants  a  system  to  be  free  of  such  defects,  especially  when  the 
system  is  made  up  of  hardware  and  software  products  from  different  sources.  An 
assignment  of  a  key  point  of  responsibility  for  the  system  is  required,  and  it's  not  clear 
how  this  factor  affects  the  cost  savings  of  the  OSA. 

Maintenance  problems  also  must  be  addressed  in  an  OSA  environment.  The  ideal 
situation  is  to  be  able  to  replace  a  module  vrith  a  like  module  from  another  vendor.  The 
office  personal  computer  (HZ)  is  often  touted  as  the  ideal  implementation  of  this  concept; 
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a  VGA  video  card  from  manufacturer  "X"  can  usually  be  replaced  directly  with  a  similar, 
but  different,  card  from  manufacturer  "Y."  llie  analogy  is  appealing,  but  is  not  always 
applicable  to  the  military  situation.  It  is  also  not  true  that  cross-vendor  module 
substitution  is  perfected  in  the  PC  world,  especially  in  more  complex  modules; 
incompatibilities  are  found  frequently.  While  it  can  be  argued  that  the  Navy  should  be 
able  to  cojM  with  the  situation,  as  commercial  organizations  do  on  a  daily  basis,  the  entire 
lo^stics  situation  needs  to  be  evaluated  further  in  light  of  the  criticality  of  the  Navy's 
missions. 

A  problem  has  been  identified  regarding  parts  substitution  of  OSA  replacement 
modules  tom  different  vendors:  the  indiscriminate  fielding  through  the  logistics  chain  of 
replacement  modules,  from  different  sources  than  the  original,  may  result  in 
unsatisfactory  performance.  This  problem  arises  tom  not  just  poor  designs  by  some 
vendors,  but  also  from  different  interpretation  of  ambiguities  in  standards  and 
specifications,  as  well  as  different  uses  for  user  definable  features  of  the  standard.  It  is 
also  the  case  that  some  vendors  claim  compatibility  with  a  standard,  even  though  they  are 
not  fully  compliant.  A  program  for  testing  of  replacement  modules,  prior  to  certifying 
them  fit  for  use  in  any  particular  application,  is  r^uired  before  the  benefits  of  OSA  can 
be  fully  exploited. 

A  frnal  disadvantage  is  that  the  Navy  does  not  control  future  releases  of  the 
standards  that  underlie  any  particular  OSA.  While  the  Navy  can,  and  does,  participate  in 
the  standards  setting  process,  the  most  commonly  used  standards  are  consensus  standards 
formulated  by  indus^  at  large.  By  using  an  open  systems  architecture,  you  potentially 
face  a  difficidt  decision  later,  i.e.,  whether  to  remain  consistent  with  the  rest  of  industiry, 
or  go  it  alone  with  an  obsolete  standard.  This  problem  arises  tom  evolving  standards 
which  may  create  products  to  replace  those  of  older  technologies  only  to  discover  that 
they  no  longer  peribim  properly  in  oldo'  systems.  Replacement  parts  in  older  systems,  as 
well  as  newly  manufactured  systems,  will  not  work  properly  unless  they  are  upgraded  to 
reflect  the  newest  release  of  the  industry  standard. 

There  is  wide  agreement  that  OSA  systems  can  reduce  initial  outlays  in  the  early 
development  phases  of  a  system.  However,  we  do  not  know  whether  the  benefits  imputed 
to  OSAs  in  the  Engineering  &  Manufacturing  Development  (EMD)  portion  of  the  system 
life  cycle  are  naaintained  aB  the  way  through  it  The  costs  of  continuous  retesting  of  new 
replacement  modules  may  be  greater  than  the  initial  cost  savings  of  the  OSA. 

Implementing  an  effective  open  systems  modular  avionics  architecture  requires  a 
simulation,  modeling,  and  testing  capability  to  validate  candidate  architectural  concepts. 
The  capability  is  needed  to  validate  design  logic,  to  ascertain  expected  systems 
perfomiance  with  respect  to  standard  benchmarks,  and  to  test  changes  before  committing 
to  a  specific  design.  When  the  OSA  approach  is  fully  implement^,  the  Navy  probably 
will  need  a  facility  that  is  a  center  of  excellence  in  simulation  and  modeling. 

It  is  also  necessary  to  test  hardware  and  software  against  the  selected  standards  to 
ensure  inter  operability  of  products  tom  various  vendors  when  used  as  an  integrated 
system.  Testing  of  hardware  should  include  evaluation  of  performance  over 
environmental  extremes  to  guarantee  adequate  operation  in  uhe  avionics  environment. 
This  environmental  testing  is  especially  critical  if  commercial  off-the-shelf  (COTS) 
hardware  is  selected  for  use.  Such  hardware  is  not  usually  designed  specifically  for  the 
militaiy  avionics  en  vironment.  Therefore,  a  testing  capability  must  be  achieved  for  OSA 
to  be  fully  beneficial. 
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When  technologically  innovative  solutions  arc  offered,  there  is  an  element  of  risk 
present  due  to  unknown  performance  and  reliability  issues.  Selected  flight  test 
demonstrations  might  be  required  to  gain  the  confidence  in  the  technology  and  to  reduce 
risk  to  the  program  manager  prior  to  acquisition  decisions.  When  selected  flight  testing  is 
coupled  with  ground-bas^  simulation  and  modeling,  it  becomes  possible  to  mitigate  risk 
at  low  cost. 


3-6  Buses  Provide  Architecture  Communications 

The  term  bus  is  used  a  lot  in  the  context  of  computers  systems,  but  the  word  "bus" 
is  applied  to  more  than  one  thing.  These  different  uses  of  the  term  "bus"  aU  have  similar 
purposes;  transferring  digital  computer  data  from  one  place  to  another.  Beyond  that 
similarity,  however,  the  various  uses  of  the  term  are  different.  In  this  section  arc 
described  some  common  forms  of  bus  that  might  be  found  singly,  or  in  combination,  in 
avionics  computer  systems. 


3-6.1  Box-to-Box  Interconnect  Buses 

One  familiar  type  of  bus  is  the  bex-to-box  inserf  ace  buses,  an  example  of  which  is 
MIL-STD-1553.  Such  a  bus  defines  the  inter-box  wiring,  the  connectors,  the  pin 
assignments,  and  the  operational  protocols  governing  how  several  boxes  in  the  same 
system  talk  together.  The  concept  of  this  type  of  bus  is  similar  to  the  more  familiar  Local 
Area  Network  (LAN)  used  in  modem  offices.  The  LAN  allows  computers  in  different 
elements  of  the  organization  to  communicate  with  each  other.  Similarly,  the  box-to-box 
15S3-style  interconnects  allow  the  different  elements  of  the  avionics  suite  to 
communicate  with  each  other. 


3-6.2  Peripherals  Interface  Buses 

This  form  of  bus  is  used  to  interconnect  peripherals  within  a  computer  system. 
For  example,  the  circuit  cards  within  a  computer  need  to  talk  to  hard  disk  drives,  floppy 
disk  drives,  CD-ROM  drives  and  other  peripheral  devices.  To  accomplish  this  job,  Ae 
designer  may  opt  to  use  a  peripherals  bus  such  as  the  Small  Computer  Systems  Interface 
(SCSI)  bus.  A  plug-in  SCSI  bus  controller  will  be  connected  to  the  computer 
motheiboard  ("backplane  bus"  —  see  below),  and  in  turn  is  connected  via  a  multi- 
conductor  cable  to  the  peripherals.  Most  personal  computers  have  at  least  one  of  these 
types  of  bus,  as  does  the  Navy  standard  desktop  computer  (DTC-2)  used  in  TAMPS. 

A  related  type  of  bus  is  intended  to  bring  together  several  different  types  of 
equipment,  which  may  or  may  not  be  computers,  and  cause  them  to  function  as  a  system. 
While  a  box-to-box  interface  bus,  or  a  regular  peripherals  bus,  might  simply  operate  as  a 
communications  pathway,  buses  such  as  the  IEEE-488  General  Purpose  Interface  Bus 
(GPEB)  serve  a  dmerent,  if  similar,  function.  The  IEEE-488  GPIB  is  intended  for  use  in 
automated  test  equipment,  and  uses  a  central  computer  controller  to  execute  a  program 
that  performs  tests  and  measurements.  In  this  type  of  bus,  the  "listeners"  and  "talkers"  on 
the  bus  act  as  peripherals  of  a  single  controlling  computer.  For  example,  radio  receiver 
sensitivity  tests  might  use  a  central  computer  driving  as  peripherals  ra^o  test  equipment 
such  as  DC  power  supplies,  signal  generators,  distortion  meten,  voltmeters,  and 
oscilloscopes.  Each  piece  of  discrete  test  equipment  is  fltted  with  an  IEEE-488 
compatible  interface  connector,  and  its  operation  is  under  die  conbx)]  of  the  central 
computer. 
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3*6 J  Backplane  Bus«> 

The  backplane  bus  defines  the  internal  motherboard  of  a  computer  system; 
connectors,  pin  assignments,  opmtional  protocols,  etc.  Modules  (printed  circuit  boards) 
plug  into  the  backplane  bus,  which  serves  the  interconnection  Unction  to  allow  modules 
to  communicate  with  each  other,  as  well  as  draw  power  from  the  system.  The.  purpose  of 
the  bacl^lane  bus  is  to  defme  and  standardize  the  way  plug-in  circuit  cards  talk  to  each 
other,  similar  to  the  way  MIL-STD-1553  defines  how  boxes  talk  to  each  other.  The  47C 
bus  used  in  the  A-6E  mission  computer,  and  the  advanced  JIAWG  bus  ai-e  examples  of 
current  military  computer  backplane  buses;  the  VMEbus  and  Futurebus+  are  examples  of 
commercial  backplane  buses  (both  of  which  are  now  being  adopted  to  military  pur^ses). 
It  is  often  the  case  that  the  backplane  bus  standard  will  also  defme  the  plug-in  printed 
circuit  cards,  card  racks,  and  other  mechanical  aspects  of  the  system.  In  some  cases,  for 
example  the  VME  bus,  a  subsidiary  specification  is  used  to  define  the  mechanical 
aspects. 


3-6.4  Sub-Buses  Within  The  Backplane  Bus 

Backplane  bus  usually  contains  several  sub  buses  that  are  also  commonly  called 
"buses."  These  include  such  functions  as  address  bus,  data  bus  (or  data  transfer  bus), 
priority  internet  bus,  arbitration  bus,  and  utility  bus.  While  the  backplane  bus  is 
important  to  the  outside  user  insofar  are  selecting  the  right  plug-in  cards  is  concerned, 
these  sub  buses  are  rarely  important  to  the  outside  user  (although  often  critically  so  to  the 
system  designer  and  progranuners). 

A  problem  that  is  sometimes  seen,  however,  is  that  the  backplane  bus  will  have 
either  unused  or  "user  configurable"  pins  or  data  pathways.  Wj^e  these  features  were 
intended  to  improve  flexibility,  they  have  die  effect  of  creating  conflicts  when  different 
after-market  vendors  produce  cards  that  use  these  features  in  incompatible  ways. 

It  is  often  the  case  that  a  computer  will  have  an  internal  baciqilane  bus,  which  is 
transparent  to  the  outside  world,  as  well  as  a  plng-in  card  that  contains  the  box-to-box 
interface  bus.  The  baciqiiane  bus  controls  internal  operations,  while  the  box-to-box  bus 
controls  inter-box  operations. 

When  the  same  word  —  such  as  "bus"  —  is  used  for  several  different  things  it 
makes  understanding  a  more  difficult.  Understanding  these  differences  ' is  key  to 
understanding  the  architectures  of  modem  computer  based  avionics  systems. 
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4-0  MAJOR  AVIONICS  ARCHITECTURES 


This  section  describes  some  of  the  current  and  evolving  systems  architectures  that 
are  considered  viable  candidates  for  avionics  systems  in  naval  aircraft. 


4-1  Joint  Integrated  Avionics  Working  Group  (JIAWG) 

The  fiscal  year  1987  DoD  appropriations  Act  Conference  Report  (Report 
No.  99  1005),  dated  15  Cictober  1986,  directed  the  Service  Representatives  to  prepare  a 
joint  plan  for  the  inclusion  of  fully  integrated,  digital  avionics,  communicadoiis,  sensors, 
embedded  communications  security  and  other  electronics  on  all  aircraft  under 
development.  Accordingly  die  Assistant  Secretary  of  Defense  for  Command  Control, 
Communications  and  Intelligence  directed  the  Army,  Nav}'  and  Air  Force  prepare  a  joint 
plan  to  meet  ^e  intent  of  the  aforementioned  con^ssional  direction.  To  this  end,  the 
Joint  Integrated  Avionics  Plan  (JIAP)  for  New  Aitciaft ,  dated  March  1987  was  prepared 
and  forwarded  to  congress  outlining  ^e  Tii-Service  plan  to  achieve  this  goal. 


4-1.1  Technology  Base/Related  Progi^ms 

The  JIAWG  draws  heavily  upon  the  bus  and  processor  technologies  of  the  Very  High 
Speed  Integrated  Circuits  (VHSIC)  and  PAVE  PILLAR  programs.  The  next  generation  of 
these  programs  continue  to  impact  JIAWG. 

The  VHSIC  program  was  begun  in  1983  to  provide  seed  money  for  the 
development  of  industrial  production  capacity  for  high  performance  military  microcircuit 
technologies.  This  was  motivated  by  the  increasing  use  of  foreign  supplied  key 
components,  as  well  as  the  divergence  of  military  and  commercial  computer  needs.  In 
order  to  assure  that  components  from  all  participating  suppliers  were  of  general  utility, 
VHSIC  established  inter  operability  standards  for  numerous  communication  channels. 
The  principal  products  remaining  from  these  efforts  are  the  standards  for  Pi  bus  (see 
discussion  contained  in  section  6-2.1)  and  TM  bus  (see  discussion  contained  in  section  6- 
2.2). 


In  1985,  the  Air  Force  Aeronautical  Systems  Division  started  the  PAVE  PILLAR 
effort  as  an  adjunct  to  avionics  concept  exploration  for  ATF.  PAVE  PILLAR  conducted 
numerous  technology  demonstrations  based  on  products  from  the  VHSIC  program,  lliese 
include  the  first  16  bit  Pi  bus  and  VHSIC  MIL-STD-1750  processor  implementations  in 
the  VHSIC  Avionics  Modular  Processor  (VAMP). 

After  completion  of  VHSIC  and  PAVE  PILLAR,  the  VHSIC  products  became  the 
responsibility  of  JIAWG.  JIAWG  management  funded  numerous  risk  reduction  efrorts 
designed  to  mature  and  validate  the  VHSIC  inter  operability  specifications.  These  efforts 
included  detailed  gate  level  simulation  of  vendor  design.*:  intended  to  identify 
implementation  and  specification  problems  with  JIAWG  updates  to  the  VHSIC 
specifications. 

The  JIAWG  Advanced  Avionics  Architecture  (A^)  is  an  integrated  avionics 
architecture,  based  on  open  architecture  principals.  The  A^  level  of  integration  is  both 
physical  and  functional.  Physical  Integration  is  implemented  in  the  avionics  suite  as  a 
processing  network  with  high  levels  of  connectivity  among  the  processing,  storage,  and 
input/output  (I/O)  elements  to  support  real-time  exchange  of  data,  dynamic  task 


Advanced  Avionics  Architecture  &  Technology  Review 


allocation,  hierarchical  built-in  diagnostics,  and  other  system  cajpabilides.  Functional 
Integration  is  a  cocnxiinated  functioning  of  Ae  elements  of  the  avionics  suite  as  a  single 
information  processing  entity  to  implement  fusion  of  data  from  multiple  sources, 
synthesis  of  cockpit  display  contents,  and  other  capabilities  based  on  sha^  data  and 
processing.  (Figure  4-1.1)  The  Open  architecture  tenant  is  based  on;  explicit  provision  for 
expansion  or  upgrading  through  the  incorporation  of  additional  or  higher  performance 
elements,  definition  of  interfaces,  including  physical,  functional  to  facilitate  integration  of 
new  or  additional  system  capabilities  and  elimination  of  proprietary  features.  It  has  not 
been  detmnined  if  any  JIAWG  specifications  will  have  proprietary  features. 
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FIGURE  4-1.1  -  JIAWG  Advanced  Avionics  Architecture 

The  JL\WG  Standards  and  Specifications  are  deHned  by  the  Common  Avionics 
Baseline  (CAB)  consists  of  Specifications,  Standards,  and  other  appropriate  documents 
defining  an  inventory  of  modules,  interconnects  and  design  tools  which  can  be  used  to 
assemble  avionics  systems  for  multiple  aircraft  while  maintaining  a  high  level  of 
commonality.  The  documents  define  items  such  as  hardware  components,  software 
modules,  and  system  integration  tools.  The  JIAWG  standards  and  specifications  are 
released  periodically  as  the  CAB,  based  on  the  major  milestones  of  the  three  primary 
JIAWG  programs.  The  current  release  is  CAB  in/Rev  3.  Table  4-1,  CAB  Release  Dates, 
shews  that  Ae  release  dates  are  driven  by  major  milestones  of  the  three  primary  tactical 
aircraft  programs. 
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Table  4-1.  CAB  Release  Dates 


DATE 

PROGRAM  MILESTONE 

I 

January  88 

All  three  programs 

n 

December  88 

All  three  programs 

m 

April  89 

All  three  programs 

m.  Revision  2 

April  90 

LH  Milestone  n 

m,  Revision  3 

November  90 

ATF  Milestone  n 

m.  Revision  4 

TBD 

AFX  Milestone  I 

IV 

October  94 

ATF,  LH  Milestone  m, 

AFX  Milestone  n 

V 

October  95 

AFX  Milestone  m 

Four  areas  of  standardization  are  being  addressed  by  the  JIAWG,  are  listed  below: 


4-12  Core  Avionics 

Core  avioni*:s  axe  the  modular  computer  resource  assets  that  can  be  integrated  into 
the  platfonn  to  implement  data,  signal,  and  other  central  processing  functions  required  in 
an  integrated  avionics  suite.  The  Core  Avionics  include: 

•  Architecture  — 

•  Backplane 

•  Data  Buses 

•  Packaging 

•  Power  supplies 

•  Processors 


4-1 J  Mission  Avionics 

Mission  avionics  includes  sensors.  Communications,  Navigation,  Identification/ 
Communications  Security  (CNI/COMSEC),  inertial  navigation,  and  other  aspects  of  the 
integrated  avionics  suite  which  furnish  offensive,  defensive,  and  mission  management 
functions. 


4*1.4  Supportability 

•  Configtiretion/Data  Management 

•  n^/Training 

•  R&M/Ground  Support 
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4*I,J5  Software 

•  Ada  Language/Real  Time  Support 

•  Software  Engineering  Environment 

•  Software  Standards  &  Practices 

•  Software  Reusability 


4-1^  JIAWG  Standards  &  Specification  Descriptions  for  Core  Avionics 

The  JIAWG  standards  and  specifications  are  described  in  the  following  sections. 
The  section  on  Core  Avionics  and  in  particular,  he  Architecture,  Proc(;ssor,  Data  Bus  and 
Backplane  standards  and  specificadens  are  done  in  more  detail  than  the  other  sections 
because  of  its  applicability  to  the  present  study.  The  JIAWG  core  avionics  are  described 
in  the  section  below. 


4- 1.6.1  Architeemre 

The  JIAWG  architecture  standard  (J87-01)  describes  an  open  system  arciiitecture 
which  provides  provisions  for  expansion  and  upgradability  throu^  the  explicit  definition 
of  all  avionics  system  interfaces.  The  JIAWG  arclutecturc  provides  the  overall 
description  of  the  structure  and  function  of  an  avionics  system,  including  the  top-level 
functional  partitioning,  network  topology,  signal  and  data  communications  protocols, 
hardware  and  software  interfaces,  and  procedures  for  system  control  and  resource 
management  Modules  form  the  basic  component  or  "building  block"  of  the  JIAWG 
architecture.  Modules  may  be  grouped  in  clusten  to  provide  avionics  functions.  Ousters 
may  be  grouped  to  create  system  elements  which  provide  sub-system  capabilities.  Figure 

4-1,6. 1  depicts  the  A^  hierarchical  structure. 

This  architecture  approach  provides  an  avionics  system  which  has  flexibility,  is 
fault  tolerant,  can  be  recoi^gured,  and  has  the  abilit/  to  share  resources. 
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Figure  4- 1.6.1  -  JIAWG  hierarchical  structure. 


_ PiviCCSSQfS 

Data  Pnxessinp  Modules.  The  following  modules  are  used  as  applicable  within  a 
data  processing  system  element  in  which  the  primary  data  path  among  i^ules  is  the  JPl- 
bus. 


16  Bit  Processor  provides  the  necessary  computational,  control,  data  storage, 
interface  and  BIT  capability  to  configure  a  single  or  multiple  processor  system  that 
perform  the  data  and/or  control  processing  for  an  advanced  'ntegrated  avionics 
architecture.  This  specification  is  based  on  MiL-STD-nSO. 

32  Bit  Processor  provides  the  necessary  computational,  control,  data  storage, 
interface  and  BIT  capability  to  configure  a  single  or  multiple  processor  system  that 
perform  the  data  and/or  control  processing  for  an  advanced  integrated  avionics 
architecture.  This  processor  conforms  to  either  of  tiie  32  bit  Computer  Instruction  Set 
Architecture  Specifications,  as  described  by  JIAWG  CAB  document  J89-M2D1. 

Siynal  Processor  is  a  general  purpose  processing  element  employing  either  of  the 
32  bit  Computer  Instruction  Set  Architecture  Specifications,  as  described  by  JIAWG 
CAB  document  J89-M2D1. 
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^.6.3 _ Data  Buses 

The  following  data  transmission  types  are  used  for  connecting  system  elements. 

Higii  Speed  Data  Bus  (TlSDRt.  The  HSDB  Protocol  shall  be  as  defined  in  the 
Linear  Token  Passing  Multiplex  Data  Bus  Protocol,  as  described  by  JLAWG  CAB 
J88-N2.  The  HSDB  is  a  fiber  optic,  linear,  token  passing  data  bus  capable  of 
50  MBPS  data  rate. 

Signal  Data  Distribution  Network  {SDDNi.  High  speed,  low  latency  data 
transmissions  wUl  use  the  JIAWG  SDDN  as  defined  by  the  Signal  Data  Distribution 
Network  Specification,  as  described  by  JIAWG  CAB  document  J89-N5.  This  nctworic  is 
a  point-to-point,  fiber  optic  data  link  operating  at  rates  on  the  order  of  hundreds  of 
megabits  per  second  and  interconnecting  apertures/signal  conditioners  with  core 
processing 

^  yideo  Data  Distribution  Network  rVDDhn.  High  speed,  low  latency  di/iital  video 
data  transmissions  will  use  the  JIAWG  VDDN  as  defined  in  the  Video  Data  Distribution 
Network  Specification,  as  described  by  JIAWG  CAB  document  J89-N6.  This  network  is 
a  point-to-point  fiber  optic  link  operating  on  tlie  order  of  hundreds  of  mtjgabits  per 
second  and  interconnecting  crew  sf/vtion  video  displays  with  core  processing. 

High  Bandwidth  The  HBI  will  provide  the  primary  path  for 

transrmssion  of  high  bandii’idth  data  between  core  processing  system  elements.  J89-SP- 


MIL:STD:.1S53  Daia  Bus.  The  1553  is  a  1  MBPS,  serial,  multiplex  data  bus, 
employing  wire  medium,  with  a  command  response  protocol. 

MIL:iSTD.-177j  Data.Eu5-  Tits  1773  is  a  1  MBPS,  serial,  multiplex  data  bus, 
employing  a  fiber  optic  media,  with  a  command  response  protocol  identical  to  MIL-STD- 


MIL-STD-176Q  Stores  Interface.  Stores  control  and  data  interronneets  shall  use 
the  MEL-STD- 1760  interface  standard. 

Dtscittc.s  Selection  Criteria.  The  use  of  discretes  between  system  elements  in 
architectures  compliant  with  this  standard  is  discouraged,  and  shall  be  limited  to 
interfaces  which  are  judged  inappropriate  using  MIL-STD-1553  or  HSDB 
implcmcnwtions.  Discrete  interfaces  wiil  be  selected  to  provide  maximum  reliability  and 
maintainability. 


irl.M _ Backplane 

All  module  interconnects  will  meet  the  requirements  of  the  Module  Interconnect 
Docuntent,  as  described  by  JIAWG  CAB  document  J87-N1. 

„ ,  JIAWG  Parallel  Inter  Module  Bus  f.TPl-BusV  The  JPI-bus  is  defined  by  the 
JIAWG  Pl-bus  Specification,  as  described  by  JIAWG  CAB  document  J89-N1A. 

JIAWG  Test/Maintenance  Bus  fJTM-busL  The  JTM-bus  is  defined  by  the 
JIAWG  ^-bus  Specification,  as  described  by  JIAWG  CAB  document  J89-N1B.  The 
JTM-bus  is  a  serial  path  for  test  and  maintenance  control  and  data  communications  witl^ 
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a  systeiu  element.  The  bus  is  a  linear,  master-slave  protocol,  multi-drop  medium 
operating  at  a  clock  rate  of  6.25  MHz. 

Utilities.  Module  interconnect  discretes,  power  distribution,  and  grounds  will  be 
those  identiHed  in  the  Utility  Signals  Specification,  as  described  by  JIAWG  CAB 
document  J89-N1C.  There  shall  be  no  other  discretes  included  in  the  module 
interconnection. 

Local  Memory  Bus  (LM-busl.  The  LM-bus  shall  be  used  to  interconnect  the  EM- 
32  module  with  its  host  DP-CAP-32  processor  module  as  defined  in  the  Local  Memory 
Bus  Protocol  SpedEcation,  as  described  by  JIAWG  CAB  document  J89-N1D.  The  LM- 
bus  is  a  single-master,  parallel,  high-speed,  very  low-latency  direct  memory  access 
(DMA)  bus.  This  bus  shall  be  used  within  a  cluster  between  a  processing  module  and  an 
extended  meroc^  module  when  the  on-board  processor  memory  is  not  large  enough  to 
support  application  program  needs. 

Signal  Processing  Network  (SPNl.  The  SPN  will  be  defined  in  the  Signal 
Processing  Network  SpeciHcation,  as  described  by  JIAWG  CAB  document  J89'N1E  (to 
be  developed,  see  J9()-SP-01).  The  SPN  provides  high-speed,  data  transmission  paAs 
between  n^ule  porforming  a  common  function.  The  SPN  will  be  a  network  switching 
concept  which  supports  simultaneous  interconnections  of  any  independent  pair  of  sources 
and  destinadons  of  data  connected  to  a  network. 

User  Con.sole  Interface.  (UCIFl.  The  UCIF  is  defined  in  the  User  Console 
Interface  SpeciBcation,  as  described  by  JIAWG  (^B  document  J89-N1F  or  the  User 
Console  Interface  Specification  for  32  Bit  Modules,  J89-N1H.  The  UCDF  defines  all 
software  development  interface  functional  capabilities  that  shall  be  supported  by  JIAWG 
modules.  This  is  done  for  both  system  level  testing  of  hardware  and  software  system'^, 
and  for  specific  testing  of  the  user  software. 

Signal  Processing  Bus  fSP-Busi.  The  SP-bus  will  be  defined  in  the  Sif.nal 
Processing  Bus  Specification,  as  described  by  JIAWG  CAB  document  J9()-N  IJ.  The  SP- 
bus  provides  labeled  message  communications,  control,  and  event  signaling  between 
clusters  or  functional  elements  (sec  J89-SP-01}. 


4-1.6.5 _ Cackaginfi 

JIAWG  architectures  are  implemented  using  a  modular  electronics 
approach.  This  approach  utilizes  standard  electronics  modules  inte^ated  in  mt^^ 
racks  and  interconnected  via  an  electrical  backplane.  Modules  in  the  integrated  avionics 
suite  now  must  conform  to  the  Standard  Hardware  Acquisition  &  Reliability  Program 
(SHARP)  Standard  Electronic  Module  Format-E  (SEM-E)  as  specified  in  MDL-STD- 
1389.  This  standard  defines  the  physical,  electrickt,  and  environmental  characteristics 
for  standard  avionics  modules.  JIAWG  modules  rely  on  various  cooling  systems 
concepts  for  normal  operation  and  to  achieve  reliability  requirements,  (^vrent 
generation  cooling  systems  include;  conduction,  air,  and  liquid  flow  through. 

Standard  Module.  The  JIAWG  Standard  Module  specification  (JS8-G2B)  is  bcin;} 
developed  that  addresses  the  physical  and  dcctrica\  characteristics  for  developing 
avionics  modules  which  meet  the  Form,  Fit,  Function  and  Interface  (F^I)  requirements 
necessary  to  implement  JIAWG  architectures. 
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Standard  Connector.  The  JIAWG  Stanc^  Connector  specification  (J87*G2A) 
deHnes  the  physical  (form,  fit)  and  electrical  (interface)  characteristics  of  the  JIAWG 
module  connector. 


4>  1.6.6  Power  supplies 

The  following  modules  will  be  used  as  applicable  for  power  conditioning  within 
integrated  rack/enclosures. 

Airborne  Standard  Power  Supply  Specification.  J88-M7A.  This  module  is  a  270 
VDC  input,  5  volt,  SO  ampere  output,  airborne  power  supply. 

Airborne  Standard  Power  Supply  Specification.  J88-M7B.  This  module  is  a  270 
VDC  input,  multiple  output  power  supply  with  outputs  of  +15V  tt  2  ampere,  -15V  at  2 
ampere  and  5V  at  30  ampere.  _ 

Aitbome  Standard  Power  Supply  Specification.  J88-M7C.  This  module  is  a  28 
VDC  input,  5  volt,  32  ampere  output,  airborne  power  supply. 


4-1.7  JIAWG  Standards  &  Spedfication  Descriptions  for  Mission  Avionics 

ICNIA  The  integrated  CNI  system  as  defined  by  this  standard  will  be  capable  of 
perfoonning  any  subset  of  the  following: 

•  Communications  functions: 

•  Radio  navigation  functions. 

•  Identification  functions. 


4-1.8  JIAWG  Standards  &  Spedfication  Descriptions  for  Supportability 

Module  designs  will  conform  to  JIAWG  specifications  for  Reliabili^  and 
Maintainabiliw  (J88-G3),  Configuration  Management  (J88-G4),  and  Integrated  Logistics 
Support  (J88-G6)  supportability  requirements. 

Module  design  will  suppon  system-level  diagnostics  and  testability.  The  design 
and  implementation  of  all  electronic  equipment  shall  provide  fail-safe  features  to  erisure 
personnel  safety  during  all  phases  of  operation  and  maintenance.  Additional 
supportability  requirements  are  contained  in  the  individual  module  specifications.  Hie 
aniidpated  operating  and  maintenance  environment  is  specified  in  the  Standard  Module 
Specification,  J88-G2B,  Environmental  Requirements. 

ILS/Training  JIAWG  ILS  elements  are  defined  in  DoD  Instruction  5(XX).2.  ILS 
responsibilities  will  flow  down  from  contractor  to  subcontractor  through  tiie  Logistics 
Support  Analysis/ Logistics  Support  Analysis  Record  (LSA/LSAR)  process  as  drscribed 
in  MIL-STD-1388/1A  and  Iv'IIL-STD-1388/2A.  The  LSA  program  will  be  a  single, 
analytic  effort  interfaced  with  the  design  process  and  systems  engineering  process. 
Derived  requirements  are  contained  in  die  Integrated  Logistics  Support  Standard,  J88- 
G6. 
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R&M/Ground  Support  Common  module  designs  will  be  compatible  with  a  two- 
Icvcl  maintenance  concept  and  shall  minimize  dependence  on  depot  special  test 
equipment.  Detwlj^  requirements  are  contained  in  the  Reliability  and  Maintainability 
Specification,  J88-G3,  and  in  individual  module  specifications. 

Configuration  and  Data  management  System  module  designs  will  be  controlled 
in  accordance  with  the  JIAWG  Configuration  Management  Plan,  J88-G4. 


4-1.9  JIAWG  Standards  &  Specification  Descriptions  for  Software 

.  .  Ada  L^euaee/Real  Time  Support.  The  JIAWG  software  task  group  is  currently 
participating  in  the  development  of  the  following  concept  papers  which  have  application 
to  this  interface: 


•  Common  Ada  Run-time  (CART),  and 

•  Catalog  of  Interface  and  Function  Options  (CIFO). 

These  documents  represent  tiic  current  state  of  progress  in  the  area  of  a  common 
operational  run-time  environments.  When  a  sufficient  number  of  the  associated  issues 
are  resolved  and  appropriate  detail  is  available,  those  documents  will  be  proposed  as 
specifications  or  standards  in  a  future  CAB  release. 

SfltoaK  EngihfiCring  EaYilQnmcnt.  The  Software  Engineering  Environment 

will  support  the  development  of  an  A3  OFP  in  accordance  with  the  JIAWG 
Software  Engineering  Environment  Specification,  as  described  by  JIAWG  CAB 
document  J89-S3.  — 

. .  Software  Standards  fe  Praeticcs  for  Software  Reusability  The  OFP  software 
^mtecture  should  support  reuse,  system  modularity  and  reconfiguration.  The  current 
CAB  document  set  contains  the  following  concept  papers  which  discusses  the  issues 
associated  with  reu.sabUity  within  the  OH's  of  the  JIAWG  weapon  systems: 

•  J89-S7  Softvi'are  Reuse  Concept  Paper,  and 

•  J89-S9  Software  Reuse  Domain  Analysis  C^oncept  Paper. 

These  documents  represent  the  current  state  of  progress  in  the  area  of  software 
reuse.  When  a  sufficient  number  of  the  associated  issues  are  resolved  and  appropriate 
detail  is  available,  those  concept  papers;  will  be  proposed  as  specifications  or  standards  in 
a  fuiure  CAB  release. 

^  .  Software  Develoument  Standard.  The  OFPs  for  JIAWG  programs  shall  be 

developed  in  accordance  with  DOD  STD-21 67 A.  The  JIAWG  Tailored  DOD-STD- 
2167 A,  J89-S6,  shall  be  utilized  as  the  standard  approach  to  tailoring  DOD-STD-2167A 
and  its  applicable  Data  Item  Descriptions  piDs). 
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4-2  Next  Generation  Computer  Resources  (NGCR) 

The  NGCR  program  provides  aii  open  system  architectural  framework  for 
computer  resource  hardware  and  software  standards  capable  of  meeting  the  Navy's 
mission  critical  computer  resource  (MCCR)  requirements.  It  encompasses  all  tactical 
embedded  computer  resources  aboard  the  full  range  of  naval  systems  and  platforms, 
including  aircraft,  surface  ships,  submarines  and  shore  locations.  Iliese  standards  provide 
a  mix  of  low,  medium  and  high  performance  systems  to  meet  the  diverse  computing 
needs  of  future  naval  systems.  The^  penmt  program  managers  and  system  develops  to 
design  and  build  MCCR  systems  with  enhanced  levels  of  product  commonality  arid  inter 
operability.  Products  conforming  to  NGCR  standards  ^1  be  implemented  in  a  wide 
range  of  naval  systems  and  will  provide  for  a  full  spectrum  of  functions  hrom  data 
manipulation  and  communications  routing  to  signal  and  symbolic  processing. 

NGCR  interface,  protocol  and  service  standards  are  intended  to  become  the 
primary  mechanism  by  which  the  Navy  alters  its  traditional  development  and  acquisition 
strategies  for  standard  embedded  computer  hardware  and  .xiftware  resources.  The 
purpose  of  this  transition  is  to  maximize  the  potential  benefit.,  inherent  in  applying  an 
open  systems  architecture  (OSA)  approach  to  the  development,  procurement  a^  up^i^e 
of  future  tactical  airborne  weapons  systems. 

The  Navy,  through  the  NGCR  progr^,  has  selected  an  industry-based  open 
systems  architecture  and  corresponding  acquisition  approach  which  stresses:  reliance  on 
industry  trends  and  investments  in  hardware  and  software  tecimologies,  increased  market 
competition,  inter  operability,  modularity,  and  the  ability  to  Held  cost-effective 
technology  improvements  in  a  timely  nuuiner. 

Three  general  areas  of  standardization  are  being  addressed  by  the  program; 
multiprocessor  interconnects,  multi  system  interconnects,  and  software  interfaces.  Nine 
standiuds  are  being  defined  or  selected  in  the  standardization  areas; 

A.  Multiprocessor  Interconnects 

•  Baseline  Backplane  and  Modular  Open  Architecture 

•  High  Speed  Data  Transfer  Network  (HSDTN) 

«  High  Performance  Backplane 


B.  Multi  system  Interconnects 

•  SAFENET 

•  High  Performance  Local  Area  Network  (HPLAN) 

C.  Software  Interfaces 

•  Operating  System  Interface 

•  Project  Support  Environment  Interface 

•  Graphics  Interface 

•  Data  base  Management  System  Interface 


I 

I 

I 

I 

I 

I 

I 
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4-2.1  NGCR  Standards  Descriptions 

The  NGCR  standards  are  described  in  the  following  sections.  The  section  on 
Multiprocessor  Interconnect,  and  in  particular,  the  Baseline  Backplane  and  Modular 
Open  Architecture  standard  is  done  in  more  detail  than  the  other  sections  because  of  it 
applicability  to  the  present  study. 


4-2.2  Multipracessor  Interconnects 

The  three  NGCR  multiprocessor  interconnects  are  described  in  the  section  below. 


4-23  The  Baseline  Backplane  and  the  NGCR  Modular  Open  Architecture 

The  baseline  backplane  and  the  NGCR  modular  open  architecture  is  discussed  in 
MIL-STD-2205  /nrej/flce  Standard  for  a  Modular  Open  Architecture  (Draft)”.  The 
NCCR  modular  open  architecture  breaks  computer  and  electronic  systems  into  board 
(module)  level  components  with  standard  interfaces  between  the  boar^.  Figure  4-2.3. 1 
shows  ^e  three  NGCR  standard  board  form  factors  and  some  intended  applications  for 
each.  The  DEEE  896.5  standard,  Futurebus+  Military  Profile  Specifications  ,  and  its 
referenced  documents,  provide  the  details  for  each  form  factor.  The  three  form  factors 
are  the  MIL-SEM-E  intended  for  integrated  rack  use,  MIL-IOSU  intended  for  ATR  box 
and  6U  VME  replacement  use,  and  MIL-12SU  intended  for  milder  environment  cabin 
avionics  and  shipboard  use. 


r 


Heiicopters 
Tacti<^  AC-new 
Shipboard 


(-.6"x~8.5") 


Helicopters 
Tactical  AC-retrofit 
Shipboard _ 


(-.10.4"x-.n.3") 

Cabin  Avionics 
Shipboard 


Figure  4-2.3. 1  -  NGCR  Board  Form  Factors  and  Applications 

Figure  4-2.3.2  shows  the  standard  board  level  interconnects  for  the  NGCR 
program.  These  are  the  IEEE  896  Futurebus-)-,  the  IEEE  1394  High  Speed  Serial  Bus, 
and  the  High  Speed  Data  Transfer  Netwoik  (HSDTN).  Detailed  pinout  and  other 
speciEcations  for  Futurebus+  and  Serial  Bus  are  contained  in  IEEE  896.5.  While  the 
Futurebus+  is  the  primary  backplane  inteiconnea,  the  audliaiy  Serial  Bus  is  used  for  test 
and  maintenance,  software  debug,  low  bandwidth  data  transfer  and  other  purposes. 
Customized  local  interconnects  among  a  few  boards,  input/output  interconnects, 
backplane  discretes,  control  and  status  registers,  power,  grouiuding,  mechanical  interfaces, 
and  thermal  interfaces  are  also  defined  in  IEEE  896.5. 
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]  Serial  Bus  &  Dtsaetes 

fc^HSDTN^  Hiah.  Speed  D^ta  Transfer  Network 


Figure  4-2.3. 2  NGCR  Modular  Open  Architecture;  Board  Level,  Sensor  / 
Display,  and  Inter-rack  Interconnects 


4*2.4  The  High  Speed  Data  Transfer  Network  (HSDTN) 

The  HSDTN  augments  the  baseline  backplane  (Futurebus-i-  /  Serial  Bus  linear 
buses)  with  a  backplane  switched  network  and  a  b^kplane  ring  network.  Figure  4-2.3J2 
shows  HSDTN  used  as  a  switched  network.  This  figure  also  shows  the  MSDIN 
extended  links  connecting  to  sensors  and  displays  as  well  as  interconnecting  separate 
racks.  This  sensorAddeo  extended  interconnect  network  contains  1-f  GBPS  point  to  point 
links  for  bringing  very  high  speed  sensor  information  to  processing  racks,  for  driving 
displays  with  refresh  memory  remote  from  the  display,  and  for  interconnecting  racks  at 
baclqplane  speeds.  The  H;SDTN  allows  multiple  simultaneous  conversations  among 
boards  and  among  Futurebu&4  clusters.  It  also  allows  simultaneous  distribution  of  sensor 
data  to  multiple  racks,  and  distribution  of  video  data  from  multiple  racks,  for  fault 
tolerance  or  other  purposei;.  The  IEEE  1596  Scalable  Coherent  Interface  (SCI), 
Asynchronous  Transf^er  Mode  (ATM),  and  Fibre  Channel  are  the  three  leading  candidates 
for  selection  as  the  base  standt\^  for  HSDIN. 
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4-2  J  High  Performance  Backplane  (HPB)  Standard 

The  third  multiprocessor  interconnect  standard,  the  High  Perfomoance  Backplane 
(HPB),  has  not  yet  been  initiated,  but  the  effort  will  start  in  September  1997.  Can^date 
technologies  for  the  HPB  mostly  revolve  around  the  use  of  optics,  although  further 
improvements  to  electrical  protocols  have  not  been  ruled  out.  Optical  technologies  of 
interest  include  fiber  optics,  free  space  optics,  optical  switches,  etc.  Electrical 
technologies  of  interest  include  lower  power,  lower  latency  protocols,  and  higher 
perfomumce  electronics. 


4-2.6  NGCR  Modular  Open  Architecture  Features 

Table  4-2.6. 1  contains  a  “Requirements  versus  Supporting  Features"  itemization 
for  the  NG(^  modular  open  architecture.  It  show  the  specific  features  developed  for 
satisfying  the  various  system  requirements. 


Table  4-2.6.1.  NGCR  Modular  Open  Architecture  Features 


l&ystem  Requirement 


Modular  6pen  Architecture 
Supporting  Feature 


re 


'OTinance 


Emerging  multi-hundred 
megahertz  computer  chip  support. 


f^uturebusT  at  up  to  6.4  (jRPS  is  16  times  faster 
than  previous  buses 

HSDTN  at  up  to  8  GBPS  on  each  leg  of 
switched  networic 


Power 


Cache  coherent  shared  memory 
Low  heat  i.3  volt  powa 


•  Emerging  ultra  high  density 
electronics  support. 

Gnomical  systems 


High  performance  flow  through  cooling  (under 
development) 

Based  on  widely  used  conuneicial  standardTm 
allow  use  of  economical  commercial 
electronics  technology 


•  Defines  interfaces  so  components  from 
different  vendors  can  work  together  and  be 
used  in  multiple  systems  providing  economies 
of  scale 

•  At  the  board  level  so  components  are  “small" 
enough  that  they  can  be  developed  on  vendor's 
own  money  thereby  shifting  development  costs 
away  from  government 


•  Supports  ruggedized  and  mil-spec  versions  of 
standard  conomercial  boards 

«  Supports  full  ATR  size  boards  on  0.8"  pitch  to 
accommodate  cheaper  high  profile  devices  and 
heat  sinks  up  to  0.2"  for  economical  but  high 
capacity  air  flow  through  cooling 
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Table  4-2.6.i.  (coniinued)  NGCR  Modular  Open  Architecture  Features 


Open  architecture  allows  system  development 
from  previously  developed  components  as  well 
as  piecemeal  upgrades  vvith  newer  components 


ee  board  sizes  to  fit  efficiently  into  me 
available  space  in  different  platforms; 

•M1L-12SU  (~10.4"x~11.3") 

•MIL-IOSU  (-6"x~8.5") 

•  ME--SEM-E  (~5.88'’x-6.68") 


our  environmental  levels  sup 

•  Gommerciai  of  the  shelf 

•  Ruggedized 

•  Full  mil-spec  (shipboard) 

•  Full  mil-spec  (airborne) 


ery  high  pofoimance  backplane  and  switched 
network  (HSDTN)  allow  combining  of  data 
^m  different  sensors 

•  Cache  coherent  shared  memory  (as  well  as 
message  passing)  for  efficient  tightly  coupled 
processing 


•  Serial  bus  for  test  and  maintenance,  software 
debug,  and  miscellaneous  functions 

•  On  board  stress  and  error  history  log 

•  On  board  revision  history  log 

•  Live  insertion  (some  form  factors) 


«.  Standard  umt  for  real  time  non  intrusive  aeoug 
of  integrated  systems 

•  Both  cache  coherent  shared  memory  and 
message  passing  for  either  tightly  or  loosely 
coupl^  systems 


HSDTN  provides  standard  mesh  (or  other 
interconnea  for  up  to  650(X)  processors. 
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Table  4-2.6.1.  (continued)  NGCR  Modular  Open  Architecture  Features 


•  Optional  liDcr  optic  contacts  in  oacKpiane 
connector 

»  HSDTN  may  optionally  have  fiber  optic 
physical  layer 


Standard  pin  assignments  tor  commonly  used 
such  as  Mil-Std  1553,  Mil-Std  1397  and  others. 


Connector  space  allocated  for  custom 
interconnects  among  a  few  boards  making  up  a 
multi-board  functional  clement 


Modules  with  dual  buses  may  use  one  bus  as  a 
secondary  bus  to  form  clusters  or  other  bus 
structures. 


I  *  ki  all 


volt  power 

•  Separate  analog  ground 

•  Gock  signal 

•  Serial  bus  to  be  used  as  RF  control  bus 

•  Optional  coax  contacts  in  backplane  connector 

•  Optional  board  covers 


•  Clock  coordinauon  accuracy  to  50  ns  or  better 

•  Up  to  256  priority  levels  for  deterministic 
scheduling 


assuied  memory  erase  message. 


uclear  event  shutdown  discrete. 


ower  fail  imminent  warning  message  an 
discrete  allows  orderly  shutdown 

Battery  backup  power 


uturehus+  provides  the  speed  to  handle  many 
signal  processing  applications  on  single  linear 
bus 

HSDTN  provides  a  switched  network  for  si^al 
processing  applications  requiring  multiple 
simultaneous  ^ta  transfers 
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4*2.7  Standards 

The  lcx:al  area  network  standard  has  been  in  preparadon  since  January  1987,  and 
was  scheduled  for  final  publicadon  in  September  1992.  The  network  is  a  dual-ring,  token 
passing  LAN-based  standard  for  inter  computer  and  computer-to-peiipheral  data  transfer. 
It  is  based  on  the  ANSI  X3T9.5/84-89  Fiber  Distributed  Data  Interface  (FDDI)  standard. 


4JL7.J.—  High  Pcrfonnancc  Nctwork-Standaid 

The  HPNET  working  group  will  be  started  in  September  1992,  with  publicadon  of 
the  standard  targeted  for  March  1^7. 


4-2.7.2  Software  Interfaces 

Four  different  software  interface  areas  are  being  standardized,  and  these  are 
described  in  the  secdons  below. 


4=2.7.3 _ Operating  System  Interface  (OSIFl  Standard  | 

The  OSEF  effort  commenced  in  March  1989  to  prepare  a  commercially-based 
family  of  operating  system  (OS)  interfaces.  Following  the  r^uirements  definition  and  a 
survey  of  available  technologies  and  standards  activities,  POSIX  (IEEE  1003)  was 
selected  as  the  baseline  standard  for  the  NGCR  OSIF  stand^s.  The  Operating  System 
Working  Group  is  now  actively  involved  in  the  IEEE  1003  project  to  participate  in  the 
POSIX  standai^  definition.  Tliis  set  of  standards  will  address  systems  which  are  Ada- 
oriented,  real-time,  distributed/networked,  multi* level  secure,  reliable  and  realizable  on 
heterogeneous  processors.  The  initial  standards  will  be  published  in  October  1995. 


^JA _ Project  Support  SnYicgnmgnt  (PSEIStondanl _ 

The  PSE  standardization  effort  was  initiated  in  April  1991,  and  will  define 
commercially-based  PSE  framewoik  interfaces  and  protocols.  The  standards  will  not 
define  suindard  tools  or  tool  sets  to  be  mandated  for  use  in  Navy  systems,  but  rather  will 
focus  on  tool  integration  mechanisms,  data  interchange  mechanisms,  and  the  logical 
contents  of  project  data  repositories.  The  adoption  of  a  harmonized  set  of  standards  for 
PSE  intofaces,  services,  and  protocols  will  provide  a  means  for  better  integration  within 
a  PSE  and  better  interaction  between  and  among  different  PSE  implementations.  These 
standards  will  be  used  in  the  development  and  deployment  of  Navy  hardware  and 
software  applications  in  the  mid-  and  late- 1990s.  This  work  is  being  carried  out  in 
concert  with  industry,  DoD,  government,  and  national  and  intemat'onal  standards 
organizations.  The  Software  Technology  for  Adaptable  Reliable  Systems  (STARS) 
program  and  the  National  Institute  of  Standards  and  Technology  (NIST)  are  prominent 
among  the  groups  with  which  the  group's  work  is  being  coordinated.  The  draft  PSE 
standuds  will  be  available  starting  in  late  1995,  with  tlie  final  set  targeted  for  publication 
in  September  1998.  The  primary  objectives  of  the  standard  are  to:  alow  the  "mixing  ;u]d 
noatching"  of  various  PSE  tools  from  tUffoent  vendors,  minimize  user  traming,  provide 
hardware  and  language  independence,  achieve  host  interchangeability,  respond  to  the 
requirement  for  use  of  Ada,  achieve  compatibility  with  the  other  NGCR  standards,  and 
span  a  wide  range  of  applications. 
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- Data  Base  Management  System  (DBMS)  Interface  Standard 

The  DBMS  standard  effort  was  initiated  in  May  1991  with  the  preparation  of  a 
white  paper  and  organization  planning  for  the  working  group,  which  was  to  be  fonned  in 
September  1992.  This  standard  will  define  DBMS  interfaces  for  naval  systems  which  are 
typically  real-time  or  cridcal-timc,  heterogeneous,  distributed,  language  and  operating 
system  independent,  network  independent,  secure,  and  fault  tolerant.  Cutrent  trends  in 
commercial  and  military  DBMS  technology  as  applied  to  C3,  sensor,  intelligence  and 
weapon  systems  will  be  assessed  to  define  standard  interfaces  for  a  broad  range  of 
platfoim  applications.  Publication  of  this  standard  is  scheduled  for  September  1998. 


4-2.7.6  Gi-aphics  Language  Interface  Standard 

The  Graphics  Interface  Standard  working  group  was  also  scheduled  to  commence 
in  September  1992,  and  has  a  scheduled  standard  publication  date  of  September  1998. 


4-2.7 .7  NGCR  Standards  Applied  to  an  Avionics  System 

Figure  4-2.7.7.1  illustrates  the  application  of  the  various  NGCR  interface 
standards  to  an  integrated  avionics  system.  These  hardware  and  software  standards  are 
designed  to  allow  the  mixing  and  matching  of  components  from  different  vendors  in  an 
airci^ 
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Figure  4-2.7 .7.1  -  NGCR  Applied  to  Avionics 
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4-2  J  Multi  System  Interconnects 

These  interconnects  provide  rack-to-rack  or  box-io-box  comniunication.  They 
arc,  in  fact,  local  area  networks  (LANs).  Two  different  complementary  LANi^,  one 
medium  speed  and  one  high  speed,  arc  being  standardized:  SAFENET  and  a  yet  to  be 
selected  High  Performance  Network  (HPI^. 


4-2.9  Common  Operating  Environment  (COE) 

Ck>mmercial-off-the-shelf  (COTS)  computer  resources  are  being  examined  by  the 
U.S.  Navy,  and  in  some  cases  adopted  for  service  use.  As  part  of  this  effort,  the  services 
are  defining  a  common  operating  environment  (COE)  for  shipboard  and  ashore  tactical 
computers.  The  use  of  the  COE  for  airborne  applications  is  not  well  defined  at  this  point, 
but  should  be  considered  where  applicable.  The  COE  is  a  collection  of  specifications  and 
designated  standardized  commercid  hardware  and  software  products.  The  U.S.  Navy,  the 
U.S.  Air  Force  and  the  U.S.  Army  arc  in  close,  if  not  complete,  agmement  conceming  the 
COE.  Specified  are  the  Sun  workstation,  UNIX  operating  system,  POSIX,  X-windows, 
MOTIF  and  certain  other  software  packages.  The  Navy  DTC-2  and  TAC-3  computers  arc 
compliant  witli  the  COE. 


4-3  VMEbus 

One  of  the  principal  computer  backplane  architectures  used  thus  far  in  the  COE  is 
the  industrial  VMEbus.  The  VMEbus  is  one  of  several  competing  commercial  standard 
microcomputer  buses.  As  recently  as  1991  it  was  consider^  state-of-the-art  for 
applications  requiring  more  computing  power  than  the  MS-DOS  or  Macintosh  class  of 
desktop  computers.  The  VMEbus  was  designed  to  accommodate  a  wide  range  of 
processors,  including  most  of  the  newer  Complex  Instruction  Set  Computer  (CISQ  and 
Reduced  Instruction  Set  Computer  (RISC)  designs.  Its  heritage  processor  is  the  Motorola 
MC68XXXX  family.  Products  based  on  Vi^bus  are  widespread,  and  include  such  things 
as  process  control,  analog  and  digital  data  acquisition,  digital  graphics  and  other 
applications  where  high  sp<^  processing  is  n^ded. 

The  ori^ns  of  the  VMEbus  are  found  in  the  iate  1970s  when  microprocessor 
integrated  circuits  Erst  gained  widespread  acceptance.  Motorola  Semiconductor,  Inc. 
intr^uced  the  VERS  Abus  architeemre  that  accommodated  their  VERSAnKidules,  which 
were  in  turn  centered  around  the  company's  MC68000-series  16-bit  and  32-bit 
microprocessors. 

VMEbus  evolved  as  a  European  adaptation  of  VERSAbus.  The  original  concept 
was  developed  at  Motorola's  Euro^an  Microsystems  Group  in  Munich,  Germany,  and 
was  based  on  the  standard  Eurocs^  printed  wiring  boards.  In  CX:tober  1981  Motorola 
(USA),  Mostek  (USA),  Signetics/Phillips  (USA  and  Netherlands),  and  Thompson/CSF 
(France)  placed  ^eir  veraion  of  the  Vh^bus  specification  in  the  public  domain  in  order 
to  allow  others  to  develop  compatible  products.  The  IEEE  and  ANSI  began  working  on 
the  specification  in  1983,  and  by  June  1987  the  VMEbus  speciEcation  was  finalized. 

The  VMEbus  standard,  ANSI/EBEE  1014-1987,  deEnes  the  digital,  electrical  and 
mechanical  attributes  of  an  interface  backplane  ("motherboard"  in  PC  tenninolo^)  that 
allows  assorted  pressor,  functional,  intenace  and  interface  control  minted  circuit  cards 
to  be  plugged  in  and  used  together.  A  companion  specification,  issued  by  the 
International  Electro-technical  Commission  (lEC  standard  297),  deEnes  the  mech^cal 
attributes  of  the  motherboard,  backplanes,  racks  and  card  enclosures  of  the  VMEbus 
system. 
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4-4  Commercially  Supported  Avionics  Architecture  Efforts 

4-4.1  AEECandARINC 

Since  die  mid-1980s,  tlic  Airlines  Electronic  Engineering  Committee  (AEEC), 
sponsored  by  Aeronautical  Radio,  Inc.  (ARINC),  has  been  investigating  the  application 
of  new  technologies  to  advanced  avionics  systems  for  commercial  aircraft  designs  of  the 
1990s  and  beyond.  This  initiative  involved  meeting  and  consulting  with  representatives 
from  academia,  government  and  industry,  to  discuss  how  new  technologies  in  the  areas  of 
micTOclectronics,  fiber  optics,  open  systems  interconnection  (OSl),  communications,  fault 
tolerance  and  software,  could  benefit  future  avionics  generations.  From  this  work,  was 
bom  the  concept  of  the  Integrated  Modular  Avionics  (IMA)  system,  which  relies  on  a  set 
of  standardized  hardware  building  blocks  to  perform  specific  avionics  generic  functions. 
Altliough  the  IMA  architecture  is  still  in  development,  AEEC/ARINC  has  published  a 
top-level  design  guide  a.s  documented  in  ARINC  Report  651;  Design  Guidance  For 
Integrated  Mo^ar  Avionics,  dated  9  November  1991. 

Ttie  IMA  concept  is  centered  around  a  powerful  computing  capability  with  an 
operating  system  that  allows  independent  application  software  processing  within  a 
fraiiKWOik  of  strongly  partitioned  software  modules.  The  computing  capability  is  housed 
in  a  series  of  cabinets  containing  common,  interchangeable  haidware  modules  types  that 
are  interconnected  by  the  ARINC  659  backplane  bus.  The  cabinets  and  remaining 
avionics  (sensors,  displays,  controls,  actuators,  etc.)  are  interconnected  via  the  ARINC 
629  global  bus  which  forms  the  system  backbone.  Signal  formats  incompatible  with 
/VRINC  629  may  interface  tluough  remote  data  concentrators,  RF  conditioners  or  cabinet 
hardware  modules.  The  system  standard  High  Order  Language  is  Ada,  although  other 
languages  can  be  integrated.  The  haidware  provides  a  flexible  electrical  interface 
through  the  use  of  shar^  standard  resources,  while  avionicsi/aircraft  functions  are  nearly 
entirely  implemented  via  the  application  programs  (software  modules).  Figures  4-4.1a 
and  4-4.  lb  illustrate  the  typical  IMA  physical  and  functional  system  architectures. 


Figure  4-4.1a  -  Physical  Architecture 
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Specific  characteristics  of  the  ARINC  629  data  bus  ar/e  defined  in  ARINC 
Specification  629-2,  published  16  October  1991.  Key  pmmeters  and  characteristics 
include  serial  bi>dirMtional  data  transfer  at  2  MBPS,  basic  protocol  operation  in  both 
periodic  and  aperiodic  naodcs,  autonomous  midtiple-access  protocol,  directed  message 
handshaking  or  broadcast  mode,  120  terminal  capacity  \ia  non  intnisive  inductive 
coupling,  and  a  twisted  wire  medium  with  provisions  for  fiber  optics.  Terminals  ( ie., 
cabinets  or  other  avionics  systems  and  components)  can  be  interconnected  as  de^red 
throughout  the  aircraft,  thereby  eliminating  the  need  for  traditional  electrical  and 
electronics  bays,  and  affording  maximum  flexibility  with  respect  to  considerations  for 
functional  and  operational  performance,  environmental  concerns,  maintenance 
philosophy,  other  s;,^steros  integration  and  growth  potential. 

Primary  elements  of  the  cabinet  include  the  cabirxt  frame,  ARINC  659  backplane 
bus  assembly  and  hardware  modules.  The  cabinet  frame  provides  the  mechamcal  and 
electrical  environment  to  house  the  hardware  modules,  ARINC  659  bus  assembly  and 
additional  aircraft  interfaces.  The  ARINC  659  backplane  bus  assembly  provides  the  intra 
cabinet  and  external  interfaces  for  aircraft  wiring,  inter  module  t^fic  and  power 
distribution.  Figures  4-4.1c  and  4-4.1d  illustrate  the  genetic  cabinet  physical  and 
functional  architectures.  Key  parameters  and  characteristics  of  the  ARINC  659  bus 
include  serial  data  transfer,  80MBPS  throughput  capacity,  32  bit  data  words,  2  bit 
message  gaps,  tabic  driven  protocol  and  fault  tolerant  processing.  Candidate  hardware 
module  types  include  the  core  processor,  standard  I/O.  special  I/O,  power  supply,  bus 
bridge,  gateway  and  mass  memory.  To  the  greatest  extent  possible,  IMA  will  to 
standaidirx  on  a  set  of  common,  interchangeable  hardware  module  types  that  can  be 


ARMOOet 

Ooiniiiig& 

ABMar 


Figure  4-4.1b  -  Functional  Architecture 
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configured  within  the  cabinets  such  that  the  position,  mix  und  nutntKX'  of  mtxiules  can  be 
tailored  to  suite  specific  cabinet  functions.  Physical  and  functional  hardware  module 
characteristics  will  be  defined  under  separate  ARINC  specifications. 
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Figure  4-4.  Ic  -  Generic  Cabinet  Physical  Architecture 
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5-0  AVIONICS  TECHNOLOGY  DEVELOPMENT  &  REVIEW 
EFFORTS 


5-1  U,S.  Air  Force  PAVE  PILLAR  and  PAVE  PACE  Programs 

5-1.1  PAVE  PILLAR. 

The  Pave  Pillar  Program  was  an  Air  Force  funded  development  program  to 
develop  a  standard  modular  avionics  architecture.  Various  prime  contractor  and  avionics 
systeins  contractors  were  teamed  for  this  development.  The  major  elements  of  the 
architecture  were:  a  standard  instruction  set  architecture  using  16  bit  VHSIC  processors 
(MlL-STD-i750A),  a  common  signal  processor,  a  standard  parallel  backplane  bus  (PI 
Bus)  and  a  test  and  maintenance  (TM)  bus,  a  global  memory  and  a  high  speed  fiber  optic 
data  bus  using  a  linear  topology.  Other  elements  of  the  Pave  Pillar  architecture  included 
a  sensor  data  distribution  network,  a  MIL-STD-1760  based  armament  interface  and  a 
M1L-STD-1S53  based  vehicle  management  system. 

The  Pave  Pillar  architecture  was  used  as  the  baseline  for  the  ATA/ATF/LH 
programs  in  their  Denoonstration  and  Validation  (DEM-VAL)  phase  in  an  attempt  to 
achieve  common  avionics  as  prescribed  by  Congress.  The  Navy  A-12  proj^un  used  tlris 
architecture  in  the  EMD  phase  and  modular  hardware  was  developed  for  this  architecture 
before  the  program  was  terminated.  Likewise  the  Air  Force  F-22  and  Army  Comanche 
programs  used  this  architecture.  Unfortunately,  the  procurement  process  did  not  provide 
for  the  required  configuration  control  between  the  platforms  during  development  so  that 
variants  of  the  architectural  standard  produced  ha^ware  that  is  not  interoperable.  The 
Joint  Integrated  Avionics  Working  Group  (JIAWG)  has  been  attempting  to  force  these 
developments  to  common  interoperable  hardware  and  a  true  open  systems  architecture. 


5-1.2  PAVE  PACE 

The  Pave  Pace  program  is  an  Air  Force  funded  development  program  supported 
to  extend  the  modular  integrated  avionics  architecture  for  application  to  advanced 
versions  of  the  F-22  and  the  multi-role  fighter  (MRF).  The  program  is  looking  at 
advanced  data  and  signal  processors,  very  high  speed  optical  networks,  advanced 
packaging,  and  modular  sensor  configurations.  Specinc  efforts  in  integrated  modular  RF 
and  EO  subsystems  are  being  explored. 


5-2  Integrated  Communications,  Navigation,  Identification,  Avionics 
aCNIA) 

The  ICNIA  advanced  development  program  was  chartered  to  improve  the  Navy's 
war  fighting  capabili^  by  enhancement  of  aircraft  communications,  navigation, 
identification  (CNI)  avionics.  The  program  was  designed  to  improve  the  performance 
and  supportability  of  Navy  tactical  and  tactical  support  aircraft  by  providing  them  with  an 
Integrated  Modular  Avionics  (IMA)  architecture.  This  would  ^  done  by  replacing  the 
hundreds  of  different  module  types  associated  with  current  black  box  implementation  of 
CNI  functions  with  the  greatly  reduced  number  of  unique  module  types  (approximately 
30)  required  for  the  ICNIA  implementation.  An  important  feature  of  the  ICNIA 
architecture  is  that  the  total  number  of  modules  required  is  based  on  the  maximum 
number  of  functions  which  must  operate  simultaneously  in  the  mission  timeline,  rather 
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than  the  total  number  of  functions  which  must  operate  over  the  period  of  entire  mission. 
This  approach  allows  the  same  individual  modules  to  be  used  to  impilement  different 
functions  at  different  times  in  the  mission.  An  important  performance  iidvantage  of  this 
approach  is  that  if  there  is  a  failure  in  an  individilhl  module,  then  moduLts  which  are  still 
functioning  can  be  reallocated  to  that  function  if  it  is  more  mission  critical  than  the 
functions  diat  they  are  cuirendy  assigned  to. 

ICNIA  was  a  joint  Navy/Army/Air  Force  non  ACAT  program  under  which  the 
Air  Force  was  designated  the  lead  service  for  tri-service  common  requinments,  and  the 
Navy  and  Army  provided  funding  for  Navy  and  Army  unique  requirements.  The  Navy 
sponsored  the  development  of  thr^  Navy  unique  functions  into  the  ICNLV  architecture: 
Link  11,  Link  4/AiXS,  and  FLTSATCOM.  The  tri-service  effort  supported  the 
development  of  Airteen  other  functions:  ARC- 199  (HF),  ARC- 186  (VhF),  Sinegars 
(VHF  ECCM),  ARC-164  (UHF),  Havequick  (UHF  ECCM),  JTIDS,  GPS,  TACAN, 
MLS,  VORyiLS,  Mode  S,  TCAS,  and  Mark  Xn  IFF.  The  ICNIA  Advanced  Eh-svelopment 
Models  (ADMs)  incorporating  all  of  the  above  functions  were  accepted  in  May  1991. 
ADMs  three  and  four  were  integrated  into  the  Integrated  Electromagnetic  System 
Simulation  (lESS)  facility  at  Wright  Laboratories.  The  Demonstration  and  Vahdation  of 
the  ICNIA  architecture  was  completed  in  FY-1992.  Basic  features  such  as  the  abiUty  to 
operate  multiple  functions  simultaneously,  conduct  built  in  test  to  identify  defective 
modules,  and  reassign  functions  from  defective  modules  to  other  modules  in  reiil  time 
were  all  demonstrated.  The  flexibility  of  the  ICNIA  architecture  to  implement  all  of 
thirteen  above-listed  CNI  functions  was  demonstrated  as  well  as  the  ability  to  later 
implement  an  additional  function  (the  Constant  Source  function).  The  ICNIA  /\DM 
development  led  to  the  development  of  a  similar  architecture  for  implementing  a  whole 
family  of  COMSEC  units  in  a  size  and  configuration  commensurate  wiA  ICNIA 
modules. 

ICNIA  technolo^  has  transitioned  to  the  Air  Force  Advanced  Tactical  Fightn' 
(ATF)  for  full  scale  engineering  development  This  technolo^  is  available  for  transition 
to  other  new  platforms  or  retrofit  to  existing  platforms  which  are  undergoing  a  majo.' 
avionics  upgr^e.  This  technology  does  not  lend  itself  to  replacement  of  functions  on  an 
individual  Ixisis,  but  rather  achieves  its  benefits  when  it  is  at^lied  to  a  group  of  functions. 
This  is  due  to  the  fact  that  the  individual  modules  of  the  architecture  are  over  designed  for 
any  one  function  since  they  must  work  gtmerically  for  a  number  of  functions.  Thus,  for  a 
single  function  implementation,  modules  which  are  optimized  for  that  function  will 
always  be  smaller,  lighter  and  cheaper.  The  payback  (in  terms  of  size,  weight  and 
acquisition  cost)  for  the  oveihead  involved  in  providing  generic  modules,  which  require  a 
limited  number  of  module  types,  occurs  because  of  the  ability  to  use  the  same  module  to 
implement  different  functions  which  are  performed  at  different  times  in  the  mission,  thus 
reducing  the  total  number  of  modules  which  are  ^uired  to  equip  a  platform.  Additional 
benefits  of  the  ICNIA  architecture  occur  in  the  life  cy  cle  suppon  of  the  avionics  system 
since  the  greatly  reduced  number  of  module  types  greatly  Truces  sparing  requirements 
and  function  specific  diagnostic  requirements. 
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5-3  Integrated  Electronic  Warfare  System  (INEWS) 

The  (INEWS)  program  is  the  result  of  the  merger  of  the  Air  Force's  New  Threat 
Warning  Receiver  and  the  Navy's  Integrated  Electronic  Warfare  System  (lEWS) 
technology  development  programs.  The  joint  Air  Force/Navy  INEWS  technology 
development  program  started  in  1983  to  develop  a  modular  integrated  Electronic  Warf^ 
suite  applicable  to  the  advanced  technology  aircraft.  TTie  INEWS  architecture  baseline 
was  derived  from  the  Air  Force's  PAVE  PIiXaR  architecture. 

During  the  Concept  Exploration  and  Definition  phase  and  Demonstration  and 
Validation  phase  lA,  five  contractor  teams  were  active  players  in  the  technology 
development  effort.  These  teams  included  Sandcrs/General  Electric; 
TRW/Westinghouse;  Loral/Hughes;  ITTA-itton  Amecom;  Raytheon/Nonhrop.  The 
INEWS  phase  lA  piogram  was  an  continuation  of  the  Concept  Exploration  and 
Definition  phase  where  the  contractor  teams  refined  their  concepts  and  detailed  the  areas 
of  major  risks.  Down  selection  to  two  contractor  teams  was  accomplished  in  early 
calendar  1986.  The  winning  INEWS  teams  were  Sanders/General  Electric  and 
TRW/Westinghouse. 

At  the  beginning  of  the  Demonstration  and  Validation  phase  IB  program  recipient 
platforms  for  the  INEWS  technology  had  not  stepped  forward  and  identifi^  themselves, 
thus  the  missions,  observability  levels,  etc.  were  generic  and  included  both  high  and  low 
altitude  flight  profiles.  Each  of  the  INEWS  concepts  were  driven  by  aircraft  survivability 
numbers  and  thus  included  more  functionality  than  was  normally  considered  for  a  tactical 
aircraft.  Weight  was  a  driving  concern,  however  and  12(X)  to  1800  pound  budget  was 
allocated  for  each  of  the  individual  INEWS  concepts.  Volume  was  specified  but  it  was 
not  a  driver.  A  cost  goal  was  imposed  which  was  in  then  year  dollars  ^uivalcnt  to  a  ship 
set  cost  of  $3.2  M.  During  the  later  portion  of  the  INEWS  phase  IB  Demonstration  and 
Validation  (DEM-VAL)  program,  tiie  ATF  j>rogram  office  embraced  the  INEWS  concept 
of  modular  integrated  EW  avionics  and  took  control  of  the  two  INEWS  DEM-VAL 
contracts  and  subsequent  activities.  The  INEWS  program  schedule  was  revised  to  more 
closely  match  the  ATF  DEM-VAL  schedule. 

The  INEWS  statement  of  work  was  modified  to  provide  for  the  fabrication  of 
INEWS  Advanced  Development  (ADM)  hardware  and  software.  The  ADMs  were  not 
required  to  be  packaged  in  SEM-E  modules,  even  though  some  functions  were  in  SEM-E 
modules  and  the  ADMs  were  not  required  to  be  entire  systems.(i.e.,  complete  RWR 
system).  The  ADMs  could  be  a  thread  within  a  subsystem  but  was  required  to  be 
sufficiently  complete  to  prove  the  function  could  be  performed.  An  example  is  the  RWR 
function  where  all  of  the  necessary  sub  functions  were  included  but  not  all  of  the 
receivers  (where  multiple  receivers  were  required)  were  not  fabricated.  Also,  only  one  of 
each  antenna  type  was  fabricated. 

The  ATF  SPO  after  taking  over  management  of  the  INEWS  activities  directed  its 
aircraft  prime  contractors  to  team  with  the  INEWS  teams  to  develop  the  Electronic 
Combat  (EC)  suite  for  the  ATF.  As  s  result  of  this  direction,  the  YF-23  prime  tcam«l 
with  TRW/Westinghouse  and  the  YF-22  prime  teamed  with  Sanders/General  Electric. 
After  the  teaming  arrangements  were  completed,  the  INEWS  program  per  se  became 
nonexistent  and  it  became  an  EC  development  effon  for  the  ATF  program.  Much  of  the 
functionality  originally  included  in  the  INEWS  concepts  disappeared  due  to  weight,  cost 
or  other  driving  constraints  on  the  ATF  concepts.  In  early  1990,  the  Air  Force  down 
selected  ATF  contractors  to  the  Lockh(»d  F-22  team  which  in  effect  relegated  all  INEWS 


page  37 


Advanced  Avimiics  Architecane  Sc  Technology  Review 


activities  to  the  SandeiVGE  team.  TRW/WEC  are  involved  with  the  RAJl-66  EC  suite 
but  this  is  an  insignificant  effort  compared  to  their  original  INEWS  concept. 

A  follow  on  program,  SEEK  SPARTAN,  wus  started  by  the  Air  Force  which 
investigated  retrofit  applications  for  INHWS  technologies  on.  existing  Air  Force  tactical 
aircraft  such  as  the  F-15,  F-16  and  F/B-111.  SEEK  SPARTAN  was  terminated  after 
approximately  two  years  of  operation.  The  Navy  is  continuing  to  evolve  INEWS 
functionality  and  technologies  not  embraced  by  the  F-22.  The  Navy  has  placed  particular 
emphasis  on  evolving  Missile  Approach/Launch  Warning  Systems  targeted  for  retrofit 
on  current  or  emerging  Naval  Tactictd  aircraft. 


5-4  Advanced  Avionics  Subsystems  and  Technology  (AAS&l') 

The  AAS&T  is  a  multi-faceted  Navy  program  for  maturing  the  advanced 
Integrated  Modular  Avionics  (IMA)  concepts  develop  under  both  this  program  and  the 
Ahr  Force's  PAVE  PILLAR  and  PAVE  PACE  programs,  and  which  have  been  adopted 
by  the  Joint  Integrated  Avionics  Woriung  Group  (JIAWG).  AAS&T  focuses  on  the 
common  A'^.vanced  Avionics  Architecture  (AAA)  directed  by  Congress  for  all  “advanced 
aircraft"  The  program  thrust  is  Navy  pect^ar  applications  of  advanced  IMA  for  current 
and  future  Naval  aimaft.  Current  task  areas  of  the  project  are:  shared  qxsrture  systems, 
digital  technologies,  avionics  photonics,  avionics  packaging,  and  situation  assessment 
and  awareness. 

The  primary  payoffs  sought  are:  (1)  reduced  risk  for  Navy  DEM-VAL  and  EMD 
progriuns;  (2)  increased  readiness  and  improved  mission  and  weapon  systems 
effectiveness;  (3)  increased  aircraft  survivability;  (4)  enhanced  technological  readiness; 
and  (5)  leveraging  of  D6D  and  industry  initiatives  and  developments  to  fulfill  Navy  needs 
at  the  lowest  possible  cost 

The  nature  of  this  program  is  such  that  medium  to  high  risk  avionics 
developments  are  demonstrate  which  have  a  potential  for  providing  high  payoffs.  The 
risk  to  future  platform  developments  are  minimized  by  maturing  and  proving  the 
technology  prior  to  avionics  integration. 


5-4.1  Documented  OPNAV  Requirements 

NAPDD  No.  083-50  documents  requirements  for:  (i)  Reducing  the  risk  for 
DEM-VAL  and  EMD  aircraft  and  advanced  avionics  programs;  (2)  Supporting  Advanced 
Avionics  Architecture  (AAA)  in  Navy  aircraft;  (3)  Reducing  avionics  systems  cost;  (4) 
Increasing  aircraft  survivability  and  lethality;  and  (5)  Leveraging  DoD  initiatives  plus 
service  and  industry  investments  in  AAA. 


5-4  J  Description  of  Project 

Current  principal  goals  of  the  AAS&T  project  are:  (1)  Demonstration  of  risk 
reduction  for  next-generation  Navy  platforms  by  demonstration  and  evaluation  of  critical 
advanced  avionics  subsystems  and  architecture  concepts  and  prototypes;  (2) 
Demonstration  of  enabling  avionics  technology  for  multi-mission  aircraft;  (3)  Application 
of  open  architecture  and  leveraging  of  commercial  software  and  technology;  (4) 
Leveraging  and  inserting  maturing  technologies  into  Navy  avionics;  (S)  Improved 
surveillimce,  detection  and  classification  of  targets  and  threats;  (6)  Licreasing  avionics 
commonalty  across  tri-service  and  Navy  platforms;  (7)  Real-time  scene  generation. 
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situation  assessment  and  mission  analysis  for  manned  and  unmanned  vehicles;  and  (8) 
Rapid  technology  transfer  to  Unmanned  Air  Vehicles  (UAVs)  via  the  Joint  Defense  Force 
(IDF). 


5-43  Rationale  for  The  Project 

The  rationale  for  this  project  is  best  outlined  in  the  following  five  statements: 

1.  For  some  forty  years,  the  threat  faced  by  each  successive  generation  of  Naval 
aircraft  has  grown  increasingly  more  lethal. 

2.  Our  response  to  this  steady  trend  has  been  to  made  the  avionics  of  each 
successive  generation  of  aircraft  successively  more  complex.  Measured  in 
terms  of  circuit  element  count,  the  avionics  of  an  aircraft  such  as  the  AX  will 
be  some  eight  orders  of  magnitude  more  complex  than  a  1950s  vintage  F-9F. 

3.  With  this  growth  in  capability  have  come  penalties:  the  cost  of  avionics  has 
grown  ^m  less  than  1%  to  be  some  40%  of  the  overall  cost  of  the  aircraft; 
the  reliability  of  avionics  has  come  to  be  a  prime  factor  both  in  availability 
and  support  costs.  We  are  rapidly  approaching  the  point  where  wc  cannot 
afford  needed  capability. 

4.  In  response  to  this  trend,  the  Air  Force  and  the  Navy  have  developed  the 
concept  of  integrated  modular  avionics  architectures;  architectures,  which  in 
connast  to  previous  black  box  concepts,  are  built  up  from  standard  functional 
modules,  heavily  based  on  the  use  of  VHSIG  and  MIMIC  technology, 
programmed  in  Ada  for  reusability  and  supportability,  extensively 
instrumented  for  built-in  test  and  diagnosis,  interconnected  by  the  high 
bandwidth  fiber  optic  data  buses  necessary  to  implement  to  complex  functions 
such  as  sensor  fusion,  and  arranged  in  a  pooled  spare  concept  for  fault 
tolerance. 

5.  But  no  platform  can  risk  commitment  to  such  a  complex  concept  with  so 
many  technological  factors  not  yet  proven.  The  thrust  of  this  effort  is  the 
development  and  demonstration  of  the  coni^ts  and  technology  necessary  for 
low-risk  insertion  of  these  advanced  architectures  in  next-generation  Navy 
platfonm. 

This  effort  is  funded  in  category  6.3A  in  that  it  evaluates  and  demonstrates 
emerging  technologies  (VHSIC,  MIMIC,  fiber  optics,  integrated  architectural  concepts) 
for  the  purpose  of  DEM-VAL  and  EMC  program  risk  reduction. 


5*4.4  Tactical  Utility 

The  potential  operational  employment  of  products  from  this  project  span  the 
entire  spectrum  of  core  and  mission  avionics.  The  IMA  and  aAA  eiforts  strengthen 
reliability  and  support  ability  factors  across  the  board.  Examples  of  war  righting  hi^ 
payoff  task  areas  are:  (1)  Situation  Assessment  &  Awareness,  to  provide  improved  air 
crew  and  system  cognitive  performance  in  high  stress,  combat  environments,  and  (2) 
Shared  Aporture  Systems,  to  enhance  aircraft  stealth  and  upgrade  avionics  survivability 
and  multi-mission  capability. 
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S-4S  Resource  Savings "  Manpower,  Logistics  Support,  Etc. 

Tlie  IMA  concept  allows  module  interchangeability  such  that  a  few  unique 
modules  car.  be  used  for  the  whole  of  the  avionics  computer  suite  (processor,  I/O  and 
memory  modules).  Module  spares  would  not  be  required  in  large  numbers^  and  lower 
maintenance  staffing  and  training  would  be  required  to  repair  or  replace  the  modules. 
The  AAA  concept  can  improve  fault  tolerance,  accommodate  common  subsystems  and 
buses,  permit  reduced  sparing  and  a  two-level  maiiitenance,  and  simplify  m^ificadons 
and  mission  reconfiguradons. 


5-4.6  Countermeasure  Resistance 

The  project  has  efforts  in  photonics  components  that  are  resistant  to  enemy 
ELINT  and  to  f^ures  due  to  EMI  or  EMP.  Advanced  algorithms  under  development  and 
planned  will  enable  radar  clutter  discrimination  between  rain  and  enemy  chaff  and 
increase  radar  detection  and  track  initiation  ranges.  One  of  the  task  areas.  Shared 
Aperture  Systems,  is  involved  in  demonstrating  electronic  beam  steering  of  the  antenna 
systems.  An  intended  function  of  beam  steering  is  to  be  able  to  reshape  the  antenna's 
radiation  pattern  such  that  v^  low  gain  nulls  are  directed  towards  a  jammer  significantly 
reducing  the  effects  of  die  jammer  through  its  penetration  via  the  antenna  system.  The 
Low  Probability  of  Intercept  (LPI)  Communications  ta^  in  the  Digital  Technologies  task 
area  has  a  indict  bearing  on  jamming  by  developing  a  communications  wave  form  that 
is  has  v^  low  detectabiUty.  This  has  the  effect  of  not  alerting  a  jamming  source  to  the 
need  to  initiate  jamming. 


5-4.7  Major  Tasks  and  Subsystems 

5^.7.  L  Shared  Apcmire  and  Multi  Function  Systems. 

This  category  includes  the  Special  Airborne  Antenna  System  (SAAS),  which  is 
jointly  sponsored  by  the  Air  Force  and  Navy  INEWS  i^g]^,  and  the  Airborne  Shared 
Aperture  Program  (ASAP)  which  includes  joint  participation  by  the  Air  Force  and  the 
Naval  Sea  Systems  C^ommiuid. 

SAAS  is  planned  to  cover  all  CNI  i^lications  operating  from  2  MHz  to  6  GHZ. 
It  is  funded  by  this  project,  the  Navy  INEWS  program  and  the  U.S.  Air  Force.  SAAS  is 
being  considered  for  application  on  the  Navy  and  Air  Force  AX  aircraft,  the  F/A-18E&F, 
and  as  an  upgrade  to  the  F-22.  SAAS  will  operate  with  today's  federated  CNI  systems  as 
well  as  the  integrated  systems  (ICNIA,  IMA,  INEWS,  etc.)  in  the  future. 

ASAP  is  designed  to  serve  as  the  aperture  for  multiple  radio  frequency 
subsystems  operating  in  the  C,  X,  and  Ku  bands,  including  radar,  ESM,  ECM,  and 
communications.  ASAP  will  utilize  technology  currently  under  development  in  the 
DoD/tii-service  MIMIC  Pixigiam  and  is  leveraging  chip  and  brassboard  demonstrations 
conducted  under  the  MIMIC  contracts.  Both  the  Air  Force  and  NAVSEA  have  expressed 
interest  in  the  ASAP  concept  and  may  jointly  sponsor  applications  to  their  own  platforms 
in  the  future.  ASAP  is  designed  to  operate  interactively  with  the  subsystems  served  by 
SAAS  such  as  ICNIA  and  INEWS.  ASAP  includes  the  design  and  demonstration  of  a 
system  resource  manager  which  wUI  automatically  select  the  proper  subsystems  to 
successfully  complete  a  mission  segment. 
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The  data  from  the  ASAP  and  SAAS  apertures  will  be  directed  to  the  signal 
processors  via  the  Sensor  Data  Distribution  Network  (SDDN),  which  is  also  under 
development  in  this  project,  where  it  will  be  processed  in  signal  processors  using  many  of 
the  tools  developed  under  this  project  as  well. 

Receivers  and  other  RF  modules  behind  the  shared  apertures  will  eventually 
benefit  from  a  planned  Air  Force  advanced  technology  transition  demonstration  program 
entitled  Integrated  Sensor  Systems  which  is  to  demonstrate  a  family  of  common  RF 
modules  can  be  used  to  replace  most  of  the  custom  modules  found  in  today's  avionics. 

The  Navy  and  Air  Force  plan  to  work  together  on  both  the  shared  aperture  and 
ISS  efforts.  Ibc  processors  which  are  used  in  conjunction  with  ASAP  will  make  use  of 
many  of  the  advanced  algorithms  (e.g.,  distinguishing  rain  from  chaff,  super  range 
detection  and  track,  etc.). 

Finally,  both  the  ASAP  and  SAAS  apertures  will  serve  as  data  sources  for  the 
Advance  Airtome  Situation  Assessment  System  (AASAS)  which  will  use  a  combination 
of  sensor  information  and  stored  data  to  render  real  time  perspective  scenes  with  threat 
oveilays  to  assist  in  situations  requiring  closed  cockpit  fUght,  coven  penetration, 
precision  strike,  battle  damage  assessment,  etc.  AASAS  is  also  in  development  under 
this  project. 


_ Digital  Technologies. 

This  class  includes  the  advanced  algorithms  work  discussed  above  as  well  as  the 
evaluation  of  the  special  processor  requirements  which  may  be  unique  to  shared  aperture 
systems  such  as  ASAP.  This  task  also  includes  the  development,  evaluation  and 
demonstration  of  fault  tolerance  technology  for  integrated  modular  avionics  systems. 
Efforts  under  this  task  serve  in  many  ways  to  connect  the  needs  of  naval  aviation  to  the 
on-going  developments  of  the  Air  Force  F-22  and  Army  LH  programs  through  interaction 
in  the  JIAWG  process.  Where  necessary,  efforts  go  beyond  the  current  JIAWG  approach 
where  new  or  q>Mial  requirements  are  foreseen  such  as  in  ASAP  or  SAAS  applications  to 
the  AX.  Since  it  is  currendy  a  premise  of  this  project  that  the  Nav>’  will  not  develop  new 
processors  but  will  adapt  those  developed  by  indust^  or  other  programs,  this  task  is  by 
necessity  highly  connected  to  most  digital  processing  efforts  including  the  F-22  GP, 
NGCR,  AN/A YK- 14,  ANAJYS-2,  and  others. 


1:4.13 _ Avionics  and  Photonics 

This  class  includes  the  development  and  demonstration  of  fiber  optic  components 
and  technology  for  applications  including  sensor  data  distribution,  SDDN  as  discussed 
above,  M1L-STD-15S3  and  MIL-STD-1773  Multi-speed  data  bus  for  retrofit  applications, 
high  speed  linear  and  ring  buses,  and  optical  back  plane  buses  for  communications  within 
an  IMA  rack.  By  the  very  nature  of  these  digital  data  communications  efforts,  they  are 
connected  to  the  hean  of  virtually  all  future  avionics  systems.  The  work  is  coordinated 
both  within  the  government  worlang  groups  (e.g.,  JIAWG)  as  well  as  national  standards 
groups  (e.g.,  S^,  IEEE).  Effons  and  products  are  conneaed  to  the  F-22,  AX,  F/A- 
18E4^,  UAV,  NGCR  and  other  programs. 
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5-4.7.4 _ Avionics  Packaging 

Like  photonics,  packaging  is  central  to  the  very  concept  of  IMA.  Efforts  are 
tightly  coupled  to  the  Navy  Standard  Hardware  And  Reliability  Program  (SHARP)  and 
the  tri-service  JIAWG  coordinated  IMA  efforts.  The  Navy  is  viewed  as  the  leader  in 
demonstration  of  the  advanced  packaging  technology  such  as  Standard  Electronic 
Modules  (SEMs),  integrated  racks,  advanced  cooling,  etc.  and  often  leads  efforts  jointly 
funded  by  the  other  services.  The  efforts  in  this  task  arc  connected  to  the  F-22,  LH  and 
AX  avionics  efforts  and  virtually  any  future  IMA  system.  Efforts  are  connected  to  othw 
tasks  within  the  project  such  as  fault  tolerance,  photonics,  ASAP,  and  others  which  will 
be  packaged  utilizing  the  packaging  concepts  of  this  project  or  which  provide 
components  for  this  tasK  (c.g.,  optical  I/O  components  for  an  optical  interconnect  system, 
bus  protocol  circuidy,  etc.). 


^•4.7.5 _ Situation  Assessment  and  Awareness 

This  effort  will  eventually  connect  with  other  efforts  in  this  project  such  as 
discussed  above  v./hen  it  is  considered  feasible  to  include  the  subsystems  required  for 
enroute  mission  planning,  mission  rehearsal,  real  time  perepective  scene  with  overlays, 
advanced  covert  penetration,  and  post-mission  analysis  in  the  IMA  system.  Present 
efforts  are  concentrated  on  demonstrating  the  algorithms  and  the  visualization  technology 
required  for  such  a  capability  in  a  manner  which  leverages  the  revolution  in  commeiciid 
pr^ssors  and  software.  It  is  an  open  architecture  approach  which  will  connect  to  efforts 
sponsored  by  the  training  systems  program,  mission  planning  program,  UAV  program, 
and  human  factors  program  which  are  currently  sponsoring  interrelated  tasks.  These 
connections  will  be  increased  in  the  future  and  will  be  expanded  to  incorporate  efforts 
sponsored  by  SDIO  and  the  USAF  (e.g.,  TENCAP  program).  A  major  objective  is  to 
demonstrate  a  single  thread  approach  to  hardware  and  software  for  mission  planning, 
training,  mission  rehearsal,  in-flight  assessment  and  awareness,  and  post-flight 
assessment  and  planning.  Future  hardware  from  this  task  will  utilize  the  hardware 
demonstrated  elsewhere  ii<  this  project  (e.g.,  packaging,  data  bus,  ASAP,  etc.). 


5-4,8  Key  Technologies 

Key  technologies  for  future  avionics  systems  include  photonics,  MIMIC,  VHSIC, 
advanced  composite  materials,  two-phase  immersion  cooling,  VHSIC  Hardware 
Descriptive  Language  (VHDL),  behavioral  simulation  and  modeling,  signal  and  image 
processing,  data  fusion,  radar,  ESM,  ECM,  antennas,  control  electronics,  LPI,  software 
engineering,  and  high  performance  computing. 


S-S  Integrated  Avionics  Development  Program  (lADP) 

The  lADP  Avionics  program  was  established  during  FY  1992  to  establish  flying 
test  bed  aircraft,  including  an  F-18,  A-6,  and  P-3C,  which  can  be  configured  to  evaluate 
advanced  avionics  developed  for  new  airoraft  (c.g.,  F-22,  IJH,  A-12,  B-2,  etc.)  for  retrofit 
into  Navy  platforms.  The  program  is  center^  at  the  Naval  Air  Warfare  Center  — 
Aircraft  Division  (Patuxant  River,  MD),  and  is  managed  by  the  Navy  INEWS  Progi^ 
Officer  within  PMA-253.  Programs  will  have  easy  access  to  the  results  of  the  evaluation 
of  avionics  hardware  and  software  developed  for  other  programs,  as  non-development 
items,  or  ur^der  other  means. 
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5-6  Ultra  Reliable  Digital  Avionics  (URDA) 

Although  the  name  of  this  USAF/Army  funded  effort  suggests  that  it  seeks  to 
design  ultra  reliability  into  digital  avionics,  the  primary  task  is  to  develop  an  extremely 
high  performance  digital  processing  module  that  incorporates  new  interconnect, 
packaging  and  stress  management  technologies.  The  deliverables  are  targeted  for  the  F- 
22,  RAH-66  P^I  and  AX.  Because  the  packaging  is  liquid  flow  through  SEM-E  modules 
with  F-22  connectors,  little  truly  new  rnodule  packaging  technology  is  teing  developed  or 
tested.  Also,  polymer  board-to-board  interconnects  and  die  stacldng  will  used,  which 
again  are  not  new  technologies. 

There  are  two  contractors  on  the  URDA  program:  Texas  Instruments  and  AT&T, 
Both  will  be  providing  tiie  same  deliverables,  including  a  demonstration  computer 
constructed  of  the  new  processing  modules,  and  the  software  development  environment 
n  is  repacka^ng  its  Aladdin  computer  onto  an  F-22  SEM-E  module.  Multiple  Aladdin 
processors  will  be  included  on  each  SEM-E.  card,  along  with  Pl-bus  and  liM-bus 
mterfaces.  The  processors  will  be  the  R4000  and  TMS320C309  devices.  The  AT&T 
processor  design  will  use  MIPSR4000  and  TMS320C40  processor  chips  interconnected 
in  a  hypercube  topology,  packag^  on  F-22  SEM-E  modules  with  Pl-bus  and  TM-bus 
interfaces.  Both  contractors  will  develop  work  station  environments  that  stress 
supportability. 
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6-0  SYSTEM  BUSES,  NETWORKS,  AND  INTERCONNECTIONS 


fc 


Traditional  computer  architectures  in  commercial  and  military  systems  are  being 
supplanted  with  a  variety  of  new  architectures  that  support  two  key  aspects  of  mt^em 
processor  development;  very  high  memory  access  speeds  and  processor  parallelisms. 
These  developments  have  impacted  architecture  primarily  through  the  extensive 
development  of  distributed  memory  systems.  The  result  of  these  changes  drives  the 
connection  tetween  processors  on  a  tward  (for  example,  the  interconnection  between 
multi-chip  modules  (MCMs)  on  a  board),  the  connection  between  boards  (backplane 
interconnects,  for  example,  PI  Bus  and  Futurebus+),  and  the  connection  between 
workstations  (commercial)  and  equipment  racks  (military). 

Much  of  recent  improvement  in  single  processor  performance  (i.e.,  Reduced 
Instruction  Set  Computers  -  RISC)  has  come  from  super  scalar  techniques  within 
processor  design.  This  represents  parallelism  that.may  be.  achieved  without  cooperation 
of  the  application  instruction  execution.  Work.station  performance  through  the  end  of  the 
decade  is  predicted  to  increase  60%  to  100%  per  year  (doubling  every  20  months  or  so). 
Worksuition  vendors  expect  to  maintain  this  rate  of  growth  by  extending  the  degree  of 
parallel  execution  into  the  application  software  domain  -  that  is,  multiple  processors 
(perhaps  26  to  28  by  ^e  end  of  the  decade)  on  a  workstation-sized  board.  This  approach 
to  complete  processor  parallelism  calls  for  application  of  new  technology  in  the  above 
mentioned  thm  categories  of  interconnection. 


6-1  Interconnect  Buses 

6-1.1  High  Speed  Data  Bus  (HSDB) 

The  HSDB  standard  was  develop^  by  SAE  AS-2,  Interconnect  Networks 
Comminee  -  Avionics  Systems  Division,  with  DoD  input  and  direction.  The  HSDB  has 
separate  token  passing  protocols  for  both  linear  and  ring  topologies..  Both  buses  are 
designed  for  either  riber  optics  or  electrical  cable  implementation,  but  only  fiber 
implementation  is  being  seriously  considered.  The  SAE  Linear  HSDB  served  as  the  basis 
for  the  JIAWG  HSDB  standard,  which  is  very  similar  to  the  commercial  standard,  but  is 
customized  fm*  needs  of  JIAWG  class  aircraft.  Linear  HSDB  is  functionally  part  of  the 
PAVE  PILLAR  architecture. 

The  SAE  has  developed  a  series  of  standards  for  high  performance,  fiber  optic 
serial  data  buses.  These  buses  are  based  on  token  passing  protocols  for  the  arbitratration 
sequence.  Such  communications  protocols  arc  intended  to  replace  buses  such  as  MIL- 
STD-1553  in  the  near  future. 

There  arc  two  standards  for  High  Speed  Data  Bus  (HSDB)  based  on  eithor  a  ring 
or  a  linear  u^logy.  The  linear  topology  has  been  ad<^t^  as  a  JMWG  standard.  This 
bus  was  simulat^  using  gate  level  models  of  bus  interface  units  from  IBM,  Texas 
Instruments,  and  Unisys,  in  mder  to  isolate  ^lecification  ambiguities  and  inter  operability 
problems.  The  initial  h^ware  development  occurred  for  the  A- 12  Demonstration  and 
Validation  (DEM-VAL)  program.  F-22  and  RAH-66A  are  also  using  this  bus.  The 
primary  suppliers  of  bus  interface  units  for  linear  HSDB  include  Harris  and  IBM. 
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6-12  MIL-STD.15S3  and  M1L-STD.1773  Serial  Linear  Control  Buses 

IvUL-STD-1553  (with  its  MIL-STD-1773  offspring)  is  the  only  approved,  tested 
and  verified  data  bus  open  standard  currently  available  for  military  avionics  systems 
integration  applications.  This  standard  defines  a  "Command/Response"  protocol  and  a 
"linear  bus"  topology  that  supports  a  Bus  Controller  and  up  to  31  slave  Remote  Terminals 
(each  with  up  to  30  "sub-ad^ss"  functions).  Tliis  protocol  allows  data  exchange  (both 
transmit  and  receive)  only  when  and  as  ordered  by  the  Bus  Controller.  Broadcast  data 
transmission  is  accommodated  by  the  standard,  but  is  precluded  from  Air  Force 
applications  by  Notice  2  to  1S53B. 

System  survivability  and  message  integrity  arc  piovided  for  by  the  use  of  backup 
Bus  Controllers,  Dual  or  Triple  Redundant  bus  implementations  and  vcrifiication  of 
message  validity  by  the  recipient's  Status  Word  response  at  each  message  event  Message 
validity  is  based  on  the  correct  number  of  words  received  (each  word  with  projwr 
Manchester  Sync  bit  and  data  bit  coding  format,  correct  bit  count  and  valid  "parity")  with 
no  gaps  in  the  data  word  sequence. 

Ibcse  two  standards  utilize  seif  clocking  Manchester  n  Biphase  Level  data 
coding,  at  a  2  MegaBaud  modulation  rate,  to  transmit  data  at  a  1  Megabit  gross  bit  rate. 
The  media  is  defined  as  shielded  twisted  pair  wire  in  1553  and  as  optic^  fiber 
waveguides  in  1773,  with  wave  form  degradation  and  response  time  limitations 
appropriate  for  the  limited  extent  of  an  airborne  platform. 

The  protocol  was  designed  for  and  is  ideally  suited  to  "Command  and  Control" 
functions,  but  the  protocol  and  the  low  modulation  rate  limit  it's  data  transport  capability. 
Word  format  overhead  limits  the  peak  data  throughput  to  800  Kilobits  Mr  Second. 
Message  formats  consist  of  a  Command  or  Status  word  accompanied  by  0  to  32  data 
words.  The  message  length,  Command/Response  overhead  words  and  response  times 
reduce  the  bus  average  data  tliroughput  to  two  or  three  hundred  Kilobits  per  Second. 

The  need  for  greater  data  throughput  and  more  than  32  terminals  in  a  system  has 
resulted  in  evolutionary  system  growth.  Platforms  witli  5  or  more  busses  are  not 
uncommon.  These  needs  have  led  to  the  development  of  features  like  dynamic 
redefinition  of  sub-addresses  and  hierarchical  bus  networics.  The  hienuchical  network 
includes  a  "global"  bus  connected  to  one  or  more  lower  level  busses  by  a  "Gateway" 
terminal  that  is  an  RT  the  global  bus  and  the  BC  on  the  lower  level  bus.  Each  lovjta 
level  bus  may  in  turn  be  gatewayed  to  it's  own  set  of  lower  level  busses.  Thus  a  midti- 
levcl  structure  is  produced  thai  can  expand  the  number  of  ccmmunicating 
terminals/function,  almost  without  limit. 

The  piice  is  additional  message  ovetiicad  and  transit  delays,  that  progressively 
reduce  the  already  limited  data  throughput  capability  of  1553,  for  cross-level  message 
traffic. 


MIL-STD-1773,  as  presently  embodied,  extends  all  protocol,  topology  and 
message  format  features  of  MIL-STD-1553.  It  only  addresses  those  issues  resulting  fixmi 
tile  lealizatitMi  of  the  bus  m;:dia  in  opticid  fiber  waveguides,  rather  than  wire. 

Further  more,  1773  does  not  include  the  detail  specification  aspects  of  1553.  A 
jupporting  General  Specification  and  a  type  cr  application  Detail  Specification  ^ 
required  for  generation  of  interoperable  1773  bus  hardware.  The  SAE  AS-3  Avionics 
Systems  Group,  which  prepared  the  original  1773  draft  standard,  now  has  prq;ared  a 
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dratt  general  development  specification  in  support  of  MIL-STD-1773,  which  is  to  be 
circulated  for  appioval  as  a  Mil  Spec. 

The  only  current  advantages  of  1773,  over  1553,  relate  to  the  non-conductivc 
nature  of  the  media  and  the  elimination  of  the  need  for  electrical  shielding  and  it's 
attendant  weight,  to  achieve  EMI/RFI  immunity.  No  present  use  is  made  of  the  high 
frequency/Baud  rate  capabilities  inherent  to  optical  transmis.sion.  AS-3A  has  currency 
begun  work  on  a  proposed  revision  A  to  MIL-STD-1773  that  will  exploit  this  capability 
to  provide  a  further  growth  path  for  1553  based  systems. 

The  purpose  of  MIL-STD-1773 A  will  be  two  fold.  First  to  define  an  optional 
alternative  or  replacement  modulation  format  to  the  existing  unipolar  optical  Manchester 
that  retains  the  implicit  'Message  Envelope"  information  that  is  available  with  the 
Bipolar  electrical  modulation  of  1553,  but  is  lost  with  the  Unipolar  optical  modulation  of 
1773.  The  elimination  of  the  two  microsecond  delay  required  to  detect  the  end  of  a 
message  by  a  1773  to  1553  convener  will  enable  two  1553  temtinals  to  communicate 
through  external  conveners  over  1773  bus  physical  media,  within  the  required  14 
microsecond  minimum  response  time-out  period,  assuming  that  the  terminals  meet  the  12 
microsecond  maximum  response  time  limitation. 

The  second  purpose  is  to  incorporate  "Multi  Speed  Data  Rate  Transmission" 
(MSDRT)  into  the  stan<^d.  One  propos^  implementation  provides  enhanced  throughput 
by  transmitting  1  to  8  blocks,  of  8  (kta  worcLs  each  (1  to  256  total  words  per  mesuge), 
with  eight  Megabit  per  second  Manchester  coding,  between  enhanced  terminals. 
Command/Status  words  between  all  terminals  and  data  between  unenhanced  terminals 
continue  to  be  transmitted  in  the  existing  one  Megabit  1553/1773  format,  for  complete 
backwards  compatibility  with  unenhanced  1773  terminals  on  the  same  bus.  The 
enhancement  provides  peak  data  transfer  of  6.4  Megabits  per  second  and  average 
tiiroughput  of  several  Megabits  per  second,  capacity  adequate  to  replace  six  or  more 
existing  1553  busses.  The  proposed  general  specification  for  this  Dual-Speed 
enhancement  to  MIL-S'fD-1773  is  available  in  the  "MIL-STD-1773  Users  Handbook", 
available  from  the  SAE  as  document  number  AIR4508. 


6-1,3  Fiber  Distributed  Data  Interface  (FDDD  /  SAFENET 

FDDI  is  an  emerging  standard  that  offers  a  network  with  a  highly  reluble  data 
transfer,  active  link  monitoring,  station  management,  large  bandv^adth  capabilities  (1(X) 
MBPS  transmission  rate),  survivability  features,  and  the  advantage  of  fil^  optics.  An 
FDDI  network  will  prove  beneficial  in  a  variety  of  application  areas.  FDDI  implements  a 
dual  counter  rotating  ring  topology  and  uses  a  token  access  method  for  packet 
transmission. 


6- 1.3.1  FDDI  in  Avionics 

SAE's  AS-3,  Avionics  Systems  Group,  is  tasked  to  develop  and  review  fiber  optic 
and  photonics  issue.*;.  Within  AS-3  there  is  a  new  working  £^up  formed  to  develop 
Military  Fiber-Optic  Transmission  System  (MFOTS),  and  it  is  tasked  with  providing 
recommendations  dealing  with  high-speed  fiber-optic  networks  for  the  next  generation 
avionics  systems.  This  effon  includes  developing  a  system  specification  for  an  FDDI- 
based  communications  network  military  aircraft 

SAFENET  (Survivable  Adaptable  Fiber-Optic  Embedded  Network)  is  an  FDDI 
network,  defining  the  lower-layer  protocols,  and  a  set  of  middle-layer  protocols  (transpoit 
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and  network  layers  of  the  ISO/OSI  protocol  stack)  termed  die  Light  Weight  Piotocol 
(LWP).  This  LWP  resulted  from  the  realization  that  expedient,  reS-time  data  delivery 
would  be  necessary  in  a  tactical  situation.  Low  latency  and  high  throughput  must  be 
achieved  between  equipment,  especially  when  relating  to  weapons  system.  Devices 
capable  of  this  high-spe^  data  delivery  would  be  able  to  use  FDDI's  100  MBPS  data  rate 
effectively.  SAFENCT  was  developed  to  meet  the  shipboard  environment. 


6-1.4  Asynchronous  Transfer  Mode  (ATM)  Local  Area  Network  (LAN) 

ATM  was  originally  developed  by  the  telecommunications  community  as  a 
logical  layer  protocol  based  on  bandwidth  partitioning  for  the  transmission  of  large 
amounts  of  data  including  real-time  audio,  computer  data,  images,  and  video  on  shai^ 
media  point-to-point  switched  networks.  ATM  transfers  digital  information  in  the  form 
of  consecutive  cells  of  constant  length,  consisting  of  a  five  byte  header  followed  by  48 
bytes  of  information.  The  header  defines  a  virtusd  path  and  a  virtual  channel  as  well  as 
other  network  management  functions.  The  ATM  protocols  tdlow  a  node  to  establish 
static  or  dynamic  connecdons  with  many  other  nodes.  Although  ATM  is  opdmized  for 
virtual  connoidon  oriented  services,  it  can  be  used  for  connectionless  services  as  weU. 
ATM  can  be  mapped  on  top  of  various  physical  layers  such  as  Sonet,  Fibre  Channel's 
8B/10B  physical  layer,  or  FDDI's  4B/5B  physical  layer.  These  physical  layers  support 
serial  communications  over  wire  as  well  as  fiber  optics  cables  at  bit  rates  fiom  155  MBPS 
through  2488  MBPS. 

ATM  services  best  suit  longer  distance  communications  environments,  such  as 
local  area  networks  (LANs),  menopolitan  area  networks  (MANs),  and  wide  area 
networks  (WANs).  In  addition,  ATM's  isochronous  services  support  time  critical  data 
transfers  including  audio,  video,  and  multimedia.  Although  not  optimal,  ATM  can  also 
be  used  for  input  and  output  to  computers. 

The  primary  champions  for  ATM  are  a  group  of  companies  who  have  banded 
together  in  an  organization  called  the  ATM  Forum.  Their  purpose  is  to  further  develop 
ATM  as  the  primaxy  telecommunications  protocol  to  meet  all  computer  related 
telecommunications  needs.  The  ATM  Forum  numbers  idxtut  2(X)  companies  including 
the  big  names  in  both  computers  and  telecommunications.  No  national  standards  body, 
such  as  IEEE  or  ANSI  has  as  yet  become  involved  with  ATM.  However,  at  this  time  it 
seems  likely  that  ATM  will  become  the  predominate  LAN  and  long  distance 
telecommunications  protocol. 


6-U  Fibre  Channel 

Fibre  Channel  was  developed  by  ANSI  as  a  transport  protocol  for  the  predictable 
transfer  of  large  blocks  of  data  such  as  those  used  in  file  transfers,  disk  and  tape  storage 
systems,  communications,  and  imaging  devices.  Fibre  Channel  transfers  asynchronous 
infmmation  in  the  form  of  variable  len^  frames,  consisting  of  a  24  byte  heads  followed 
by  up  to  21 12  bytes  of  information.  Fibre  Channel  provides  bi-directional  ccnmections 
and  supp<^  for  packet  switching,  connected  operations,  and  connectionless  operations. 
Transmission  is  isolated  from  the  logical  protocols  so  that  a  variety  of  implementations 
are  possible.  Currently,  point-to-point  links  and  switched  topolo^es  are  defined.  The 
Fibre  Channel  physical  layers  can  support  serial  communications  ovs  copper  and  fiber 
optics  cables  at  bit  rates  from  132.8  Mbaud  to  1062.5  Mbaud. 

Fibre  Channel  is  optimized  for  input  and  output  as  well  as  communications 
between  nodes.  In  addition.  Fibre  Channel  is  also  suited  for  data  flow  between 
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proccskffs  since  it  can  provide  connection  services  and  can  guarantee  bandwidth  between 
two  nodes.  Although  not  optimized  because  of  a  large  header,  Fibre  Channel  can  also 
provide  processor  to  memory  services.  Presently  Fibre  Channel  is  competing  with  ATM 
for  connector  space  on  the  backs  of  work  stations.  While  Fibre  Channel  is  a  more  mature 
LAN  standard,  its  protocol  has  not  been  extended  into  the  telecommunications  arena  as 
has  the  ATM  protocol.  For  this  reason  its  success  may  be  limited  to  being  a  fast  flexible 
I/O  channel  to  super  computer  tapes  and  disks. 


6-1.6  Other  Network  Schemes 

ARINC  provides  standards  for  the  Airline  Indusuy  Association,  including  several 
data  bus  standa^.  ARINC-429  is  a  serial,  point-to-point  data  link  wliich  is  clocked  at 
either  lOOK  bits  per  second  or  18.6K  bits  per  second.  This  bus  is  used  in  the  airline 
industry  for  interconnecting  radio  navigation  and  flight  management  systems.  A  digital 
interface  format  has  been  published  which  provides  a  standard  communication  protocol 
for  such  applications.  Many . military  transpok  aircraft  use  this  data  bus.  In  addition.  Navy 
aircraft  which  use  over-water  navigation  aids  such  as  Omega  often  use  this  data  bus. 
ARINC-629  is  a  very  similar  dau  bus  which  is  now  emerging  in  new  commercial 
transport  designs  such  as  the  Boeing-777.  This  bus  is  intended  to  provide  more 
performance  functionality  than  AUNC-429.  As  such,  it  will  probably  appear  in 
future  notary  transport  and  special  mission  aircraft 


6-1.7  Electronics  Industries  Association  (ElA) 

EIA  publishes  tnany  data  bus  specifications  that  are  used  throughout  the  computer 
industry,  such  as  RS-170,  RS-232,  and  RS-422.  Such  buses  are  also  found  on  commercial 
transport  aircraft  and  military  airkaft.  RS'232  is  t>'pical  of  such  bus  types.  RS-232  is  a 
serial,  point-to-point  link  which  can  be  clocked  at  up  to  20,000  bits  per  second.  Normal 
transmission  rates  are  the  familiar  modem  speeds,  such  as  4SOO,  9600,  and  19200  baud. 
The  bus  protocol  defines  a  primary  bus  and  secondary  bus,  as  well  as  control  signals. 
Various  modes  of  operation  arc  defined,  such  as  full  duplex,  in  which  a  signal  is 
transmitted  and  then  echoed  back  to  the  originator,  or  half'  duplex  with  no  echo.  It  is  also 
possible  to  transmit  on  the  primary  bus  and  receive  on  the  secondary  bus,  or  vice-versa. 
RS-232  is  used  in  commercial  computer  aimliications  to  connect  terminals  to  computers. 
Aircraft  systems  normally  use  the  RS-232  interface  as  an  interconnect  to  external 
equipment,  such  as  the  console. 

RS-422  is  an  update  to  RS-232.  RS-170  is  a  serial  chaimel  used  to  control  video 
devices  and  is  found  on  many  aircraft. 


6-2  Backplane  Buses  and  Networks 

A  consequence  of  modularity  in  a  digital  computer  is  the  use  of  a  backplane  bus 
into  which  modmes  can  be  plugged.  It  is  common  prw;tice  to  associate  the  name  of  the 
backplane  bus  with  the  entire  system,  so  a  ”VMEbus''  computer  is  one  in  which  the 
VMEbus  backplane  is  used,  and  which  will  accept  plug-in  ovules  that  arc  compliant 
with  the  VMEbus  standard.  There  are  several  backplane  bus  architectures  that  have 
potential  for  naval  avionics  use. 
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6>2.1  Pi  Bus 

Pi  bus  was  originally  developed  by  the  VHSiC  program  as  a  standard  computer 
system  interface.  After  completion  of  the  VHSIC  program,  the  standard  was  transferred 
to  the  J^WG  in  order  to  support  the  primary  user  programs  (A-12,  F-22,  and  LH).  As 
pm  of  risk  reduction  activities  for  these  programs,  gate  level  modeling  of  first  generation 
n  bus  conbolici's  from  IBM,  Texas  Instruments,  and  Unisys  was  p^ormed  to  identify 
inter  operabi^ty  problems.  Numerous  hardware  demonstrations  were  also  completed.  The 
intei  operability  trouble  reports  were  used  to  p^uce  an  extensive  update  to  the  VHSIC 
Pi  bus  specification.  Subsequent  to  completion  of  F-22  DEM-VAL  phase,  the  SA£ 
formalize  the  specification  (the  requirements  are  now  the  same  as  those  contained  in  the 
JIAWG  specification)  and  established  a  User's  Group.  The  SAE  Pi  bus  specification  is 
now  in  the  final  stages  of  balloting.  A  Pi  bus  handbook  was  started  earlier  this  year. 

Pi  bus  is  a  synchronous  12.5  MHz  parallel  bus  designed  to  support  message 
passing  and  fault  tolerance.  Two  bus  widths  are  supported,  16  bit  Error  Detecting  (ED) 
and  32  -bit  Error  Correcting  (EC).  The  16  ED  bus  is  normally  implemented  as  a  dual 
redundant  pair.  The  usual  method  of  communication  is  one  of  several  block  transfer 
modes,  which  can  move  up  to  65,535  data  words  to  single  or  multiple  slaves  via  either 
physical  or  logical  addressing.  A  bus  interface  message  is  also  defined  which  allows 
communication  with  the  Pi  bus  controller  register  space.  Also,  a  parameter  write  message 
is  defined  which  allows  a  low  latency,  three  word  transfer.  Fmally,  a  datagram  is  delink 
which  is  a  non  acknowledged  block  transfer  used  for  low  latency  block  transfers. 

A  single  16ED  or  32EC  bus  requires  58  signal  lines.  A  mixed  mode  of  operation, 
in  which  16  and  32  bit  modules  are  connected  within  the  system,  is  also  supported,  which 
requires  60  signal  lines.  The  protocol  supports  up  to  32  modules  per  backplane.  However, 
due  to  module  stub  lengths  and  electrical  characteristics  of  the  backplane,  systems  often 
contain  approximately  16  modules  (or  fewer). 

Extensive  error  handling  and  real-time  support  arc  provided  in  the  Pi  bus  protocol. 
A  "suspend/resume"  feature  allows  messages  which  cross  minor  frame  boundaries  to  be 
intemipted.  An  abort  s^uence  can  be  used  to  halt  a  babbling  module.  A  48  bit  real-time 
timer  is  defined.  The  Pi  bus  specification  also  describe.s  numerous  other  error  conditions 
and  handling  procedures. 

Pi  bus  is  now  reaching  full  maturity  due  to  extensive  simulation,  hardware 
demonstrations,  aviomes  DEM-VAL,  and  operational  use.  It  was  used  for  A-12,  YF-22, 
YF-23,  is  now  found  in  F-15E,  and  will  soon  be  operational  in  EF-1 11,  F-16C  Upgrade, 
F-22,  and  LH.  Bus  loading  on  each  of  these  systems  is  quite  low  (<8%,  except  for  current 
F-16C  Upgrade  estimates  around  13%),  which  allows  room  for  future  growth.  When 
additional  performance  is  needed,  faster  transceivers,  denser  logic,  use  of  a  25  MHz. 
clock,  and  other  factors  can  be  used  to  significantly  increase  performance.  Pi  bus  is  also 
under  consideration  for  commercial  avionics  applications,  which  will  broaden  its 
technology  base. 

Pi  bus  was  designed  to  provide  a  simple,  optimized  mechanism  for  transferring 
large  blocks  of  data-  within  a  system.  The  designers  intended  the  bus  operation  to  be  a 
"send  and  forget"  asynchronous  interface,  mostly  used  in  loosely  coupled,  multi 
computing  computer  architectures.  For  this  reason.  Pi  bus  is  clearly  not  adequate  as  a  real 
time  memory  interface  in  tightly  coupled  systems,  nor  was  it  designed  for  such 
applications.  Therefore,  within  the  architectmal  paradigm  for  which  Pi  bus  was  designed, 
it  offers  a  low  risk,  highly  fault  tolerant  interconnect  system. 
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6-2  J  Test  &  Maintenance  (TM)  Bus 

The  Test  and  Maintenance  (TM)  bus  is  another  VHSIC  Phase  Two  Inter 
operability  standard.  Therefore,  its  history  and  user  base  closely  pamllels  that  of  the  Pi 
bus. 

The  final  VHSIC  version  3.0  is  used  in  numerous  systems.  However,  in  1990  it 
became  clear  that  some  additional  features  were  needed  to  support  system  diagnostics  in 
F-22  and  LH.  Tne  primary  changes  in  systems  requirements  were  an  increase  from  32  to 
251  modules  addressed  (256  logical  address  including  broadcast  and  multicast)  and  a 
defined  sequence  for  bus  mastership  (the  VHSIC  3.0  specification  is,  in  essence,  a  central 
arbiter).  As  a  consequence  of  these  new  requirements,  there  were  significant  changes  to 
the  VHSIC  TM  bus  clocking,  electrical  characteristics,  and  interrupts.  These 
requirements  are  documented  as  an  F-22/LH  specification,  which  is  identical  to  the 
current  JIAWG  document.  The  IEEE  has  t^gun  balloting  on  standard  1 149.5,  which  is 
similar  but  not  identical  to,  the  logical  layer  portion  of  the  JIAWG  specification.  The 
SAE  has  begun  a  physical  layer  specification  vdiich  will  capture  requirements  for  the 
electrical  chuacteristics. 

The  VHSIC  TM  bus  is  a  four  signal  line  (five  for  IEEE)  serial  data  bus  clocked  at 
6.25  MHz.  Systems  normally  contain  a  dual  redundant  pair  of  these  buses  in  the 
backplane.  In  addition,  many  n^ule  architectures  and  multi  chip  modules  use  this  bus  as 
a  diagnostic  port 

The  xEEE  and  JIAWG  versions  of  TM  bus  are  relatively  recent  developments 
which  are  not  of  the  same  maturity  as  Pi  bus.  However,  the  VHSIC  3.0  TM  bus  was  also 
modeled  in  the  JIAWG  gate  level  efforts,  and  is  used  in  the  platfonns  listed  for  Pi  bus 
(plus  F/A-18).  Therefore,  inter  operability  of  TM  bus  systems  from  different  vendors  will 
continue  to  be  a  problem  for  some  time,  but  this  bus  is  supponed  by  numerous  avionics 
vendors. 


6-23  IEEE-896  Futurebus-f 

The  IEEE  896  Futurebus+  is  designed  to  be  used  in  single  bus  and  multiple  bus 
systems  and  to  provide  performance  and  cost  scalability  over  time.  Although  the 
specification  is  principally  intended  for  64  bit  address  and  data  operation,  a  fully 
compatible  32  bit  subset  is  provided.  While  IEEE  896.5  Futurebus+  Military  Profile 
Specifications  allows  only  the  32  and  64  bit  versions,  commercial  Futurebus+  will  also 
scale  to  128  and  256  hits  wide.  In  addition  to  being  scalable  in  terms  of  bus  width, 
Futurebus-f  is  also  designed  to  be  scalable  in  speed  as  new  technology  is  developed. 
With  its  current  Backplwe  Transceiver  Logic  (BTL)  the  top  end  performance  Is  about 
100  nullion  transfers  per  second,  or  on  a  64  bit  bus,  6.4  GBPS.  However,  with 
differential  ECL  technology,  such  as  is  used  in  the  German  Autobahn  bus,  this  could 
scale  to  1.8  giga  transfers  per  second,  or  115.2  GBPS.  While  the  protocol  might  be 
somewhat  inefficient  at  this  rate  (the  connect  and  disconnect  phases  would  b^me 
relatively  long  compared  to  the  data  phase),  it  would  still  perform  correctly.  Futurebus+ 
takes  its  name  from  its  goal  of  being  capable  of  the  highest  possible  transfer  rate 
consistent  with  the  technology  available  at  the  time  the  modities  arc  designed. 

Futurcbus+  supports  both  a  fast  central  arbiter  and  a  slower  fully  distributed 
arbiter.  Eight  bits  of  priority  are  provided  with  beth  arbiters,  but  use  of  priority  with  the 
centralized  arbiter  slows  it  considerably.  The  priority  feature  is  direct^  specifically  at 
real  time  military  usage,  including  the  use  of  Rate  Monotonic  Scheduling. 
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Transmission  of  data  over  the  multiplexed  address/data  highway  is  governed  by 
one  of  two  inter  compatible  transmission  methods:  (1)  a  technology- independent, 
compelled  protocol,  supporting  broadcast,  bioadcall,  and  transfer  intervention,  and  (2)  a 
configurable  transfer-rate,  source-synchronized  protocol  supporting  only  block  transfers 
and  source-synchronized  broadcast  for  systems  requinng  the  highest  possible 
performance. 

Futurebus+  was  designed  primarily  as  a  cache  coherent  shared  memory  bus,  but  it 
also  supports  large  block  transfers  and  message  passing.  Spice  simulations  of  up  to  26 
boards  on  a  single  backplane  have  been  run.  lliese  have  shown  that  Futurebus-t-  will 
perform  satisfactorily  with  at  least  26  boards  if  some  restrictions  are  placed  on  which 
slots  are  used  in  partially  populated  backplanes. 

Five  commodity  integrated  circuit  vendors  are  currently  selling  or  planning  to  sell 
Futurebus-f  chips:  Nation^  Semiconductor,  Texas  Instruments,  Phillips/Signetics, 
Motorola  Semiconductor  Products,  and  LSI.  LSI  will  sell  a  single  chip  solution,  except 
for  transceivers.  They  will  also  market  a  macro  for  custom  chip  developers. 

The  disadvantage  of  Futurebus-f  is  that  it  requires  a  large  number  of  pins  on  the 
connector  and  that  it  does  not  have  an  error  corrections  mode.  To  achieve  error 
conection  requires  dual  buses  which  doubles  the  already  large  pin  count. 


6-2.4  IEEE-1394  High  Speed  Serial  Bus 

At  the  time  of  this  writing  the  High  Speed  Serial  Bus  is  in  its  final  stages  of 
development.  It  is  a  two  conductor  bus  which  has  two  variants:  (1)  A  cable  variant  up  to 
10  meters  long  designed  to  be  a  peripheral  bus  for  personal  computers  (replacing  SC^I 
and  other  interconnects)  and  running  at  up  to  200  MBPS;  and  (2)  A  backplane  version 
using  BIL  logic  and  running  at  50  MBPS  wi;h  potential  to  100  MBPS.  Because  the 
cable  version  will  be  used  in  large  numbers  of  personal  computers,  it  is  expected  to  be 
very  low  cost. 

Serial  Bus  is  specified  as  an  auxiliazy  bus  to  Futurebus-f  in  IEEE  896.5.  It  is  used 
for  test  and  maintenance,  for  software  debug,  as  an  RF  module  control  bus,  and  as  a  low 
bandwidth  general  purpose  interconnect  for  modules  which  do  not  require  the 
performance  of  Futurebus-f.  For  example.  Serial  Bus  might  be  used  as  a  communication 
path  for  load  balancing  pow^  supplies.  Serial  Bus  has  also  been  selected  by  the  military 
VME  community  as  their  auxilia^  bus  to  be  used  for  similar  purposes. 

Serial  Bus  supjrons  real  time  deterministic  scheduling  with  four  bits  of  priority 
and  the  capability  to  limit  the  length  of  transfers.  Serial  Bus  supports  fault  tolerance 
through  use  of  dual  buses.  Serial  Bus  and  Futurebus-f  both  follow  the  IEEE  1212  Control 
Status  Register  standard  so  that  the  nvo  buses  are  very  compatible.  Information  is  passed 
using  the  IEEE  1212  memory  mapped  addressing  scheme. 


6-2JS  VME  Bus,  extension  to  VME64  (Commercial  VME  Products,  IEEE) 

VME,  or  Versa-Module  Eurocard,  is  based  on  Versabus,  which  was  developed  by 
Motorola  in  the  1970$.  The  ^^sulting  bus  standard  is  documented  as  ANSI/IEEE- 1014- 
1987.  This  bus  provides  a  memory  interface,  block  transfer  of  small  messages,  and  real¬ 
time  interrupts.  The  VME  specification  de^es  four  sub-buses  withit)  the  architecture: 
data  transfer  bus,  arbitration  bus,  priority  interrupt  bus,  and  utility  bus. 
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The  data  transfer  bus  contains  a  32  bit  data  path,  32  bit  address  (non-isultiplexed). 
and  control  signals  used  to  select  various  addressing  modes.  The  arbitration  bus  is  used  to 
select  the  bus  master  via  cither  priority  based,  round  robin  (rotating),  or  user  defined 
protocols.  The  priority  interrupt  bus  is  used  to  provide  real-time  capability,  such  as  might 
be  needed  for  an  error  handler,  a  minor  frame  time  out,  timer  expiration,  or  similar 
events.  The  utility  bus  provides  power  monitor  and  other  health  discretes. 

The  data  transfers  are  asynchronous  and  can  be  performed  as  a  block  transfer  (up 
to  256  bytes)  or  single  word  (four  bytes).  Up  to  21  slots  per  backplane  are  permitted.  All 
four  sub-buses  require  94  signal  pins.  The  intcimpt  bus  and  asynchronous  jmtocol  can  be 
used  to  perform  memory  transactions,  as  would  be  found  in  a  tightly  coupled  computer 
architecture.  The  block  transfer  bus  operation  provides  conventional  message  passing 
capability. 

As  mentioned  in  the  introduction,  VKIE  is  used  extensively  in  the  workstation 
market.  Although  there  were  significant  inter  operability  problems  in  the  early  days  of 
VM£,  market  forces  and  continued  standardization  work  have  contributed  to  assure 
multiple  vendor  inter  operability  today.  Such  systems  are  also  found  in  military  aircraft, 
altiiough  applicability  has  been  somewhat  limited  to  laboratory  environments  found  in 
aircraft  operator  mission  stations.  For  tactical  applications,  subsetting  is  often  used  due  to 
the  harsher  environmental  and  packaging  constraints. 

A  64  bit  data  path  using  the  VME  protocol  is  now  in  development  by  IEEE.  This 
bus  will  be  interoperable  with  existing  32  bit  modules,  but  represents  a  significant 
performance  gain  for  full  64  bit  systems.  Although  64  bit  backplane  buses  for  tactical 
aiirraft  present  a  difficult  design  challenge  because  of  packaging  issues,  operator  stations 
in  patrol  and  anti-submarine  aircraft  will  be  able  exploit  this  technology. 

The  VMEbus  standard  accommodates  a  wide  variety  of  applications.  It  is  capable 
of  dynamic  sizing  to  allow  8-bit.  16-bit  and  32-bit  devices  to  openM  on  a  32-bit  address 
bus  and  32-bit  data  bus.  Data  transfer  rates  up  to  40  megabytes  per  second  can  be 
handled. 

The  VMEbus  backplane  may  have  up  to  twenty-one  plug-in  slot  connectors  in  a 
standard  19-inch  subrack.  If  fewer  plug-in  slots  are  us^  on  any  particular  product,  then 
the  subrack  may  be  smaller  than  19  inches.  In  addition  to  the  subr^k,  some  vendors  offer 
card  cages  that  can  be  physically  integrated  into  other  products.  In  addition  to  the 
standard  subrack,  some  vendors  offer  c^  cages  that  can  be  fit  into  other  products,  but 
which  meet  the  VMEbus  standud  for  plug-in  cards. 

Two  different  sized  Eurocards  can  be  plugged  into  the  VMEbus  backplane.  The 
size  3U  single  height  cards  are  6.3  X  3.94  inches,  and  have  a  single  96-pin  connector  on 
one  end  of  the  c4rd.  The  3U  card  can  accomnK>date  a  24-bit  address  bus  and  a  16-bit  data 
bus.  The  size  6U  double  height  Eurocard  is  6.3  X  9.19  inches,  and  uses  two  96'pin 
connectors  (desigiiated  PI  and  P2)  for  a  total  of  192  pins  along  one  edge.  The  6U  caids 
can  accommodate  32-bit  address  and  32-bit  data  buses. 


6-2.6  IEEE-1596  Scalable  Coherent  Interface  (SCI) 

The  IEEE'1S96  SCI  is  a  system  of  rings  and  switches.  It  is  intended  for  very  high 
performance  parallel  processing  -  both  small  scale  parallel  and  massively  parallel.  Rings 
and  switches  were  selected  as  the  basic  communication  medium,  because  they  require 
only  point  to  point  links  rather  than  multi-drop  T-tapped  bus  lines.  Point  to  point  links 
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provide  inherently  cleaner  signals  and  hence  can  run  at  higher  speeds  and  lower  voltages, 
in  addition,  switches  provide  for  muldple  simultaneous  conversations  among  boards  -  a 
necessity  for  highly  parallel  systems.  SCI  rings,  since  they  are  insenion  rings  witli 
bypass  buffers,  also  allow  a  limited  number  of  simultaneous  conversations  depending  on 
the  configuration  of  senders  and  receivers  within  the  ring  data  flow.  Because  two  party 
rings  degrade  into  simple  full  duplex  data  links  (one  input  and  one  output  to  /  from  each 
node),  SCI  has  been  able  to  define  interface  protocols  which  are  applicable  to  both  rings 
and  switches. 

With  its  support  for  both  rings  and  switches,  SCI  is  applicable  for  use  in  both 
switch  based  massively  parallel  systems  such  as  the  Butterfly  machine,  as  well  as  mesh 
based  architectures  such  as  Touchstone.  It  can  also  suppon  hybrids  of  the  two 
architectures. 

SCI  has  a  64  bit  address  space  of  which  16  bits  are  reserved  for  node  addresses 
allowing  up  to  65,000  nodes.  As  its  name  implies,  it  is  intended  for  use  in  cache  coherent 
shared  memory  systems.  It  uses  a  directmy  based  cache  coherency  protocol,  because  of 
the  inherent  scalability  of  that  scheme.  It  conforms  to  the  IEEE  1212  Control  Status 
Register  standard  and  supports  the  shared  memory  locks  spewed  therein.  Two  variants 
of  SQ  are  now  defined:  (1)  A  16  bit  wide  (plus  a  clock  line  and  a  flag  line)  paralld 
version  running  at  8  QBPS  on  each  point  to  point  link;  and  (2)  A  serial  version,  which 
may  be  either  electrical  or  fiber  optic,  running  at  1  GBPS.  Both  the  serial  and  parallel 
electrical  versions  use  differential  pair  links  to  improve  the  si^aUng  characteristics. 
Because  the  S(jl  protocol  requires  no  handshakes  between  boar^,  links  can  extend  for 
long  distances  limited  only  by  the  communications  medium.  Electrical  links  can  extend 
to  about  30  meters  and  fiber  optic  links  to  several  kilometers. 

While  the  baseline  SCI  is  an  accepted  IEEE  standard,  further  development  is  still 
talcing  place  on  variants.  A  low  power  version,  featuring  0.25  volt  signal  swings,  is  under 
development.  Other  link  widths  are  also  under  consideration,  including  an  eight  bit  wide 
version  and  a  four  bit  wide  version.  Higher  speed  serial  versions  are  being  investigated 
up  to  4  GBPS.  A  proposal  has  been  made  by  the  Canadian  Navy  for  a  R(^  11016  (RT) 
version  of  SCI  dubb^  SCI/RT.  SCI/RT  proposes  several  changes  for  deterministic 
scheduling,  for  improved  fault  tolerance,  and  for  higher  performance. 

Currently  three  vendors  are  developing  protocol  chips  for  SCL  These  are  Dolphin 
Technology  (Norway)  doing  a  GaAs  chip,  and  both  LSI  and  National  Semiconduaor 
doing  silicon  implementations.  Dolphin  was  scheduled  to  deliver  chips  in  first  quarter  of 
CY-93.  Convex  has  announced  that  they  will  use  SCI  in  a  new  super  computer.  Hewlett 
Packard  has  announced  that  they  will  use  SCI  to  link  work  stations  to  the  Convex  super 
computer  using  SCI. 
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7-0  KEY  TECHNOLOGIES. 


While  technological  capability  is  obviously  not  the  only  issue  in  system  design,  it 
is  nonetheless  very  important.  If  the  military  avionics  market  is  to  leverage  commercial 
technology  to  lower  development  cost  and  risk,  then  it  is  essential  that  a  clear  picture  of 
the  direction  of  such  markets  be  established.  This  picture  is  possible  on  the  basis  of  the 
industry  briefs  received  by  the  AART,  recent  analysis  by  programs  such  as  PAVE  PACE, 
and  periodic  market  previews  by  organizations  such  as  IEEE. 

Market  sizes  which  are  quoted  in  this  section  and  in  various  literature  should  be 
used  with  some  care.  Even  though  the  military  avionics  computer  quantities  are  much 
smaller  than  the  number  of  workstations  purchased,  the  militai^  still  provides  a 
significant  percentage  of  research  dollars  which  ultimately  results  in  commercial 
piquets.  As  two  examples,  MIPS  Inc.  and  Silicon  Graphics  are  both  now  thriving 
commercial  ventures  (recently  merged)  which  were  spun  off  directly  from  DoD  research. 
It  will  be  a  significant  challenge  to  develop  a  policy  which  provides  the  market  incentives 
for  the  commercial  world  to  carry  more  of  the  burden  of  such  research,  especially  when 
military  requirements  are  often  so  different  from  commercial  requirements.  The  fiirct  step 
in  understanding  this  transition  is  to  project  trends  in  the  commercial  market,  which  is  the 
purpose  of  this  section.  The  trends  are  summarized  in  the  Table  7-1  below. 

Table  7-L  1998  Avionics  Technology  Status 
HEM  STATUS 


Processors 

Packaging 


Memory 


75  MHz.,  64  bit  RISC  data  processois; 
similar  signal  and  graphics  processors. 

( 1 )  SEM-E  dimensions,  liquid  flow 
through 

(2)  Multiple  chips  hybrids  with  two  or 
more  processors  an  memory  systems. 

8192x8  SRAM 


Backplane  Buses 
Interconnects 


Software  Languages 


Emerging  Technologies 


VME64  will  be  big  in  the  comme  rcial 
world  and  also  with  some  military  users. 

Futurebus-*-  will  emerge  in  the  military 
world  for  some  mission  equipment, 
although  many  Pi  bus  users  will  remain. 

Ada  will  still  be  used,  C-h-  will  begin  to 
emerge  as  commercial  software  becomes 
reusable;  CASE  will  mature 

(1)  AD/DA  converters  will  revolutionize 
mission  avionics  by  replacing  many 
analog  devices; 

(2)  Digital  solderless  microcircuit 
interconnects;  and 

(3)  Mission  equipment  (especially  RF) 
will  become  modularized  and 
standardized 
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7-1  Generic  Technologies 

Another  technology  which  may  have  major  impact  is  the  digital  solderless 
interconnects.  This  technology  is  used  to  mechanically  attach  multi-chip  hybrids  to 
interconnect  boards  in  place  of  solder.  Solderless  interconnects  may  allow  faster,  and 
more  automated,  assembly  with  fewer  mechanical  defects,  as  well  as  more  easily 
repairable  systems. 


7-1.1  Computeiized  Engineering  Tools 

Computerized  systems  engineering  and  detail  design  tools  are  evolving  for 
hardware,  software  and  overall  systems  design.  These  tools  have  the  potential  for 
significantly  increasing  engineer  pi^uctivity,  while  at  the  same  time  increasing  overall 
quality  of  the  designs.  In  the  hardware  realm,  the  quality  issue  is  addressed  by  checking 
myriad  design  rules  and  performing  some  of  the  reliability  engineering  tasks.  Software 
tools,  commonly  called  Computer  Aided  Software  Engineering  (CASH)  tools,  can  check 
logical  design  and  a  whole  host  of  other  factors.  It  is  important  for  systems  engineers  and 
managers  to  understand  the  tools  that  are  available,  and  be  familiar  with  both  their 
streams  and  their  weaknesses. 

A  caution  is  in  order  regarding  computerized  tools.  They  do  not  replace  good 
systems  analysis,  although  they  can  enhance  the  effectiveness  of  systems  analysis.  Good 
tools  will  not  help  a  mediocre  dcsi^  organization  perform  at  high  levels.  While  they  may 
help  a  great  deal  in  such  organizations  if  properly  used,  they  may  also  either  wind  up  not 
being  used  at  all  (becoming  "shelfware")  or  being  misused  by  unskilled  practitioners  of 
the  desi^  arts.  Poorly  used  tools  can  hide  serious  problems,  not  only  in  the  design  itself 
but  also  in  the  design  organization  and  its  management 

Yourdon*  offers  some  observations  about  software  computerized  tools  that  are 
equally  applicable  to  all  forms  of  computerized  systems  engineering  tools.  He  divides 
software  tools  into  "lower-CASE"  and  "upper-CASE"  categories,  depending  on  their 
complexity,  functionality  and  capability.  ^  asserts  that  upper-CASE  tools  should  be 
reserved  for  organizations  that  are  mature,  i.e.,  process  oriented,  at  the  Software 
Engineering  Institute  (SEI)  maturity  level-2  or  above.  Lower-CASE  tools  have  a  place  in, 
and  can  be  successfully  us^  by,  less  mature  design  organizations. 

One  application  of  tools  is  in  keeping  order  as  a  design  emerges  and  evolves  to 
the  final  system.  Humans  can  only  focus  on  a  limited  number  of  items  at  a  time,  so 
designers  of  complex  systems  must  go  through  long  check  lists  every  time  a  change  is 
proposed  As  the  system  grows  more  corqrlex  the  abWty  of  human  designers  to  complete 
the  check  list  decreases,  until  eventually  some  important  detail  is  missed.  The  computer- 
based  tools  can  complete  checklists  of  derign  rules,  and  do  dynamic  simulations  that  help 
the  designer  to  understand  and  control  complex  interrelationships  between  system 
elements.  Lack  of  such  insight  often  causes  seemingly  good  designs  to  perform  pcorly  or 
incorrectly 

Designs  become  much  more  robust  when  good  tools  are  proporly  used.  Designers 
now  only  have  the  time  to  evaluate  a  very  limited  set  of  tradeoffs,  ^  ^ey  often  have  to 


>  Yoiutlon,  Edward.  Decline  and  Fall  of  the  Amarican  Propamintir.  Preniice-Hall,  Englewood 
Cliffs,  NJ,  1992 
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accept  the  first  design  that  meets  the  minimum  design  goals.  Even  thcn^  it  is  sometimes 
true  that  educated  jesses  are  passed  off  as  analysis  and  the  true  situation  is  largely 
unknown.  With  the  improved  tools  that  cit  becoming  available,  designers  will  be  able  to 
examine  hundreds  of  designs  and  pick  much  more  optimum  solutions.  It  will  be  possible 
to  debug  the  software  and  the  hardware  concurrently  before  the  system  is  ever  built.  This 
capability  is  projected  to  be  fully  available  by  the  year  2000  at  the  latest,  while  interim 
capabilities  are  being  constantly  improved  in  the  meanume. 

It  must  be  recognized  that  computerized  engineering  tools  do  not  represent  a 
"silver  bullet,"  despite  the  progress  that  has  been  made,  their  most  passionate  ^vocates 
notwithstanding.  Nor  will  they  become  silver  bullets  as  they  mature...unless  design 
organizations  that  use  them  mature  also.  However,  they  are  powerful  tools  that,  in  the 
hands  of  a  skilled  practitioner,  can  greatly  improve  tlie  systems  design  process. 


7-1.2  Emerging  Technologies 

A  significant  technological  revolution  based  on  breakthrough  discoveries 
occuned  over  the  last  few  decades.  These  discoveries  include  the  bipolar  and  field  effect 
transistor,  the  integratcJ  circuit,  solid  state,  gas,  and  semiconductor  lasers,  fiber  optic 
communications  and  sensors,  focal  plane  arrays,  gallium  arsenide  microwave  devices,  flat 
panel  displays  aitd  solid  state  power  control  devices,  etc. 

Digital  integrated  circuits,  semiconductor  and  optical  memory,  advanced 
netwoiidng  (both  electronic  and  optical),  advanced  packaging  technology,  flat  panel 
displays,  and  the  related  processing  technologies  are  being  widely  supponed  through  both 
commercial  and  government  supported  research  and  development.  These  arc  key 
technologies  which  have  dual  use  in  the  commercial  and  military  information  revolution 
which  is  taking  place. 

The  Depanment  of  Defense,  and  especially  the  Defense  Advrjiced  Research 
Projects  Agency  (DARPA),  have  begun  major  initiatives  in  Microwave  i\nd  Millimeter 
Wave  Integrated  Circuits  (MIMIC)  and  Infrared  Focal  Plane  Arrays  (IR^A).  These 
technologies  offer  the  possibility  of  extending  the  modular  integrated  avionics  concept  to 
the  sensor  area.  Similar  initiatives  in  optical  control  sensors  and  high  bandwidth 
networks  for  sensor  signal  transfer  are  also  under  consideration.  Hiere  is  however  no 
major  commercial  emphasis  at  this  time  by  the  industry  in  the  sensor  arena. 


7-2  Microelectronics  Technologies 

Microelectronics  provides  the  critical  difference  between  modem  avionics 
systems  and  earlier  desi^s.  It  is  anticipated  that  microelectronic  development  will 
continue  to  pace  the  avionics  industry,  and  will  become  even  more  imponant  in  the 
future.  In  the  sections  below  are  discussed  some  trends  in  microelectronics,  along  with 
specific  microelectronic  technologies. 


7-2.1  Trends  in  High  Density  Microelectnmics 

Microelectronics  technology  has  been  cited  year  after  year  by  the  DoD  as  one  of 
the  critical  technologies  which  serves  as  the  foundation  for  the  electronic  systems  which 
are  the  "force  multiplier"  lesponsible  for  the  US  superiority  in  weapons  systems.  The  US 
has  always  been  a  leader  in  this  technology  and,  more  importantly,  in  the  design  of 
sophisticated  systems  and  software  which  leverage  its  spenl  and  packaging  density. 
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Microelectronics  technology  started  with  discrete  transistors  and  passive  components  on 
a  circuit  board  and  quickly  progressed  to  integrated  circuits  (IC's)  consisting*  of  several 
transistors  and  other  components  on  a  single  slab  of  silicon.  These  IC's,  u.sually  called 
chips,  have  continued  to  grow  in  both  density  and  speed  while  power  per  individual 
component  goes  down.  T(^ay  it  is  possible  to  design  and  fabricate  chips  with  2100,000 
digital  gates  each  and  clock  speeds  of  100  MHz,  as  well  as  dynamic  random  access 
memoiy  (DRAM)  chips  with  4  Mbits  per  chip.  In  fact,  the  integrated  circuit  technology 
has  been  doubling  in  density  and  performance  at  an  astonishing  rate  of  two  years  or  less 
for  decades.  The  Complimentary  Metal  Oxide  Semiconductor  (CMOS)  transistors  us^ 
in  most  modem  digital  circuits  obey  a  scaling  law  which  in  effect  says  that  the  smaller 
you  can  make  tlie  components  the  faster  the  components  will  work  and  at  less  power. 
Also,  the  smaller  you  make  the  components  the  more  components  that  can  be  fit  on  a 
chip. 


The  photolithographic  technology  that  is  used  to  define  the  ultra-small  patterns  on 
a  chip  is  cne  of  the  keys  to  achieving  these  high  performance  chips.  Today's  state-of-the- 
art  chips  have  minimum  design  mles  of  about  0.7  micrometers  (millionths  of  a  meter, 
pm).  These  chips  arc  manufactured  using  photolithography  tools.  In  the  future  chips  will 
be  patterned  using  light  of  shorter  wavelengths  (i.e.,  deep  ultraviolet)  to  achieve  even 
smaller  dimensions  of  0.35  pm  to  O.S  pm.  When  photolitho^phy  reaches  its  limits  in 
terms  of  wavelength,  process  latitude,  or  other  barriers,  new  technologies  such  as  x-ray 
lithography,  electron  beam  lithography  and  ion  beam  lithography,  which  are  currently  in 
development,  will  be  ready  to  t^e  over  and  push  minimum  design  rules  down  to  0.25 
pm,  0.18  pm,  and  0.1  pm  or  even  smaller.  DARPA  and  the  Navy  are  currently  p^irsuing 
these  advanced  lithographic  technologies  both  in-house  at  the  Naval  research  Laboratory 
and  with  a  broad  cross  section  of  industry  under  the  Defense  Advanced  Lithography 
Program. 

As  the  lithographic  technology  permits  building  ever  smaller  chip  patterns,  we 
can  expect  to  see  memory  chips  increase  to  16  Mbit  DRAM's,  64  Mbit  DRAM's,  256 
Mbit  DRAM's,  then  1Gbit  DRAM's  (that  is  one  billion  bits  of  memory  on  a  single  chip) 
by  the  year  2000.  While  the  computer  memory  market  has  been  the  key  dnver  for 
increasing  density,  logic  and  analog  chips  will  also  benefit  dramatically  both  from  the 
smaller  dimensions  made  possible  by  these  new  lithographic  technologies  and  the  new 
materials  (e.g.,  thin  film  silicon-on-silicon,  gallium  arsenide,  indium  phosphide,  etc.), 
devices  and  algorithms  emerging  to  suppon  the  technology.  Logic  circuits  will  grow 
from  100,000  gate  equivalents  per  chip  to  hundreds  of  thousands  of  gates  per  chip  or 
even  millions  of  gates  per  super  chip  (a  large  slab  of  single  crystal  silicon  with  multiple 
chip  sites  and  interconnect  all  included  in  a  monolithic  circuit  equivalent  to  an  entire 
subsystem  on  a  single  large  chip).  These  logic  circuits  will  be  capable  of  operating  at 
clock  speeds  ranging  from  1(X)  hOlz  to  tens  of  giga  hertz.  Suck  $p(^  will  enable  whole 
new  systems  architectural  concepts  that  provide  more  blending  of  analog  and  digital 
circuitry,  and  eliminate  certain  functions  such  as  RF  down  converters  and  up  converters. 

Likewise,  analog  circuits  will  also  benefit  from  the  ability  to  shrink  circuit 
patterns.  Benefits  will  include  higher  efficiency,  broader  bandwidths,  lower  noise 
figures,  and  higher  frequency  operation.  In  both  the  analog  and  digital  case,  the  cost  of  a 
given  element  (transistor)  or  function  (gate,  memory  bit,  etc.)  can  be  expected  to 
decrease;  however,  the  cost  of  the  large  scale  function  (32-bit  computer,  memory 
subsystem,  transmit/receive  chip,  etc.)  will  be  much  higher  than  what  one  normally 
considers  a  component  should  cost.  The  reason  is  that  the  value  added  at  the  historical 
component  vendor  will  become  higher  as  will  the  risk  and  cost  of  designing  and 
producing  these  large  scale  functions.  In  fact,  many  of  these  component  houses  are  going 
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into  the  multi  chip  module  vending  business  which  will  permit  them  to  sell  much  larger 
scale  functions  than  they  have  made  in  die  pasL 

Multi  chip  modules  are  large  area  metal,  ceramic,  composite,  or  metal  i^trix 
housings  in  which  are  placed  substrates  made  of  ceramics,  composites,  glass,  silicon, 
polymide,  etc.  with  multiple  levels  of  metal  interconnect  and  an  array  of  chips  and  other 
passive  components.  In  some  cases,  the  chips  arc  stacked  into  three  dimensional  blocks 
to  form  extremely  dense  blocks  of  memory  or  logic.  This  type  of  packaging  is  just 
beginning  to  emerge  and  can  be  expected  to  incorporate  digital  and  analog  circuits  as  well 
as  power  supplies,  photonic  circuits,  micro  electromechanical  functions,  electro-optical 
components  and  electromagnetic  functions  in  the  late  1990s. 


The  trend  in  ever  higher  density  microelectronics  is  expected  to  continue 
throughout  die  1990s  and  is  expected  to  affect  hot  only  chip  densities  but  also  packaging 
densities.  The  costs  to  design  and  produce  these  super  large  scale  functions  are  also 
expected  to  grow  (c.g.,  $1B  capital  investment  to  get  into  the  gigabit  dynamic  ^dom 
access  memory  business)  which  will  most  likely  lead  to  fewer  vendors  and  more  interest 
in  functional  standards  and  open  architecture  systems,  at  least  initially.  In  the  long  run, 
efforts  in  much  more  sophisticated  simulation  ttmls,  computer-aided-design  tools, 
computer-aided-manufacturing  tools  and  computer-aided-test  tools,  coupled  to  the  front- 
end  of  highly  automated  chip  and  module  factories  will  lead  to  more  application  specific 
circuits  and  modules.  The  growth  in  the  technology  is  expected  to  continue  doubling 
about  every  two  years  throughout  the  1990s  and  into  the  next  century.  The  share  of  the 
market  devoted  to  military  products  will  continue  to  shrink  on  a  relative  scale  to 
commercial  applications,  even  for  products  such  as  microwave  and  millimeter  wave 
integrated  circuits  where  the  military  has  been  the  largest  user. 

For  the  military  program  manager  and  the  prime  contractor,  these  trends  in  the 
microelectronics  industry  will  necessitate  a  new  pai^gm  for  conducting  Aeir  programs 
and  business.  For  major  programs  such  as  a  new  airCTaft  development,  it  is  no  longer 
economical  to  develop  a  totally  custom  avionics  suite  because  it  be  considerably  out 
of  ^te  by  the  time  of  initial  introduction  in  the  fleet  Instead,  it  may  be  preferable  to 
develop  an  open  architecture  approach  to  an  integrated  avionics  system.  As  stated 
elsewhere  in  this  report,  there  is  probably  going  to  be  a  need  for  more  than  one 
architecture  to  meet  the  diverse  mission  requirements  of  the  services  and  all  the 
platforms,  but  many  of  the  components  of  these  architecture's  can  be  standardized  for  a 
given  time  frame.  The  Government  and  industry  will  have  to  adopt  and  manage  these 
standards  in  order  to  survive  in  a  world  where  the  commercial  marketplace,  not  the 
military,  dominates.  It  is  desirable  that  the  military  systems  utilize  or  adapt  commercial 
technology  wherever  feasible  by  cleverly  choosing  products  which  arc  foreseen  to  be 
winners,  and  arc  likely  to  be  supported  by  the  commercial  markets  for  a  reasonable 
period  of  time.  It  may  also  be  necessary  to  revamp  our  lo^stics  strategy  to  plan  for 
making  lifetime  buys  of  spare  components  early  in  the  production  cycle  of  new  platforms 
or  major  updates. 

To  implement  the  new  paradigm,  the  services  and  industry  must  be  prepared  to 
invest  ^eferably  off-line  from  any  major  prognms)  in  the  development  of  advanced 
simulation  tools  and  in  the  development  of  avionics  test  beds  for  these  advanced 
architectures. 
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While  the  objective  is  to  have  open  architecture,  it  will  also  be  necessaiy  to  have  a 
level  of  security  which  prevents  compromise  of  the  system  or  its  exploitation  by  an 
adversary. 

Because  the  services  and  prime  contractors  will  be  taking  on  more  liability  for  the 
overall  avionics  system  design  and  architecture,  it  will  be  necessary  to  develop  verifiable 
advanced  fault  tolerance  technology  to  insuie  functionality  of  all  systems. 

The  new  paradigm  also  will  likely  necessitate  certain  organizational  changes  in 
recognition  of  the  fact  that  the  aircraft  is  merely  a  seamless  extension  of  the  pilot  and 
crew  which  will  operate  as  a  single  entity  instep  of  as  a  conglomeration  of  individual 
subsystems.  Organizations  will  need  to  ^akdown  the  outmoded  historical  boundaries 
between  subsystems  such  as  CNI,  EW,  radar,  computers,  controls,  displays,  software, 
weapons,  etc.  Such  systems  will  operate  with  the  aid  of  sophisticated  resource  managers, 
sensor  fusion  algorithms  and  make  optimum  use  of  human  intelligence  and  control.  To 
facilitate  this  goal,  it  will  be  desirable  to  maintain  a  significant  number  of  on-going 
technology  developments  which  build  upon  the  successes  achieved  with  each  generation 
of  technology  rather  than  starting  from  scratch  with  each  new  program.  If  implemented 
properly,  such  an  approach  could  yield  significant  savings  to  each  program  manager  by 
reducing  risks  associated  with  starting  from  scratch,  pe^tting  an  optimum  selection  of 
systems  on-board  versus  off-board  a  given  platform,  minimizing  the  need  for  derivative 
aircraft  types,  and  lower  maintenance  costs  (years  between  scheduled  repairs).  In 
addition,  updates  would  be  much  simpler  through  the  use  of  modular  hardware  and 
software  titd  together  using  large  bandwidth  signal  and  data  flow  networks. 

While  there  are  a  lot  of  advantages  to  these  breakthroughs  in  microelectronics  and 
associated  packaging  and  interconnect  technology,  there  arc  also  some  potentially  serious 
drawbacks.  One  of  these  is  the  old  problem  of  cosmic  radiation  damage  to  logic  and 
memory  circuits  which  becomes  more  exacerbated  a.s  the  dimensions  of  these  device  and 
circuit  patterns  becomes  smaller  and  smaller.  Such  radiation  can  cause  single  event  upset 
(SEU)  or  single  event  latch-up  (SELU)  in  circuits  with  sub  micron  dimensions,  and 
increases  in  probability  of  occurrence  as  a  function  of  altitude.  This  problem  can  be 
overcome  through  proj^r  design  and  engineering,  but  points  to  a  potential  issue  in  using 
off-the-shelf  components  not  designed  for  aircraft  application.  Another  problem  which 
can  be  anticipated  in  future  systems  using  high  density  electronics  is  one  of  thermal 
density  and  the  need  to  remove  heat.  It  is  probable  that  future  systems  will  require  that 
some  form  of  liquid  cooling  be  available.  Techniques  such  as  liquid  flow  through 
modules  and  racks,  liquid  immersion,  and  higher  conductivity  materi^s  (including  light 
weight  composites,  diamond  filled  composites,  and  metal  matrix  materials)  are  among  a 
number  of  approaches  being  pursued  to  alleviate  thermal  density  problems. 

Program  managers  need  to  recognize  that  the  thermal  management  problem  is  a 
potentially  significant  weight  and  reliability  issue  and  that  integrated  avionics 
architectures  with  distributed  hardware  may  necessitate  providing  cooling  to  more  remote 
locations  in  the  aircraft.  The  trend  of  moving  more  avionics  towards  the  skin,  or 
embedded  in  the  skin,  of  an  airentft  (smart  skins)  will  continue  and  will  necessitate  new 
environmental  protection  technology.  Microelectronics  materials  other  than  silicon  (e.g., 
gallium  arsenide,  indium  phosphide,  and  silicon  carbide)  will  enable  more 
environmentally  tolerant  circuits  which  may  eventually  not  even  require  cooling. 
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7-2.1. 2 _ What  About  The  Threats? 

The  continuing  revolution  in  microelectronics  is  no  longer  unique  to  the  United 
States  and  this  picture  is  not. expected  to  change  much  in  the  foreseeable  future.  While  it 
appears  to  be  true  that  the  US  is  regaining  a  slight  lead  over  our  nearest  competitor, 
Japan,  we  will  not  likely  sec  that  gap  increase  by  any  significant  amount.  In  fact,  to  the 
contrary  we  may  see  a  more  determined  effort  on  the  part  of  other  nations  to  gain  more  of 
a  leadership  role  in  designing  logic  circuitry,  rather  than  memory  chips,  as  they  now 
surely  recognize  that  there  is  far  more  profit  in  those  chips  than  in  memo^  chips. 

Also,  with  the  breakup  of  the  Soviet  bloc  into  independent  nations  there  is  more 
emphasis  on  the  US  releasing  more  and  more  products  to  foreign  buyers.  This  trend  is 
probably  good  for  maintaining  a  strong  US  industrial  base,  but  it  also  means  that  any 
potential  ^versary  will  have  access  to  modem  microelectronics  technology  that  may 
more  current  than  what  is  in  our  present  weapon  systems.  It  can  be  expected  tiiat  even 
Thiird  World  nations  will  have  easy  access  to  the  components  need^  to  build  very 
formidable  military  systems  EW,  radar,  CNI,  and  processors.  While  these  nations  may 
not  be  able  to  field  technologically  superior  aircraft,  they  will  be  able  to  build-up  large 
inventories  of  countermeasures,  detection  equipment,  communications  equipment  and 
fire  control  systems  making  the  projection  of  air  power  more  difficult.  In  turn,  this 
increased  threat  density  and  sophistication  will  demand  even  more  capability  firom  our 
aircraft  avionics  in  the  late  1990$  and  beyond.  Also,  the  explosion  in  the  application  of 
microwave  and  millimeter  wave  microelectronics  in  more  and  more  commercial 
applications  like  (e.g.,  cellular  communications,  smart  highways,  entertainment,  security 
sensors,  etc.)  will  make  the  problem  of  distinguishing  friend  from  foe  far  more  difficult 


7-2  J  Random  Access  Memory  Chips 

Random  Access  Memories  (RAMs)  are  the  true  "commodity"  parts  of  the  digital 
age.  All  computers  need  some  place  to  store  data  during  prognra  execution,  and  that  is 
what  random  access  memory  provides.  Because  RAM  is  so  universal,  it  is  produced  in 
very  large  quantities,  and  the  ability  to  get  more  working  chips  from  a  given  wafer  size 
translates  directly  into  profit.  Primarily  for  this  reason,  advanced  lithography  has  usually 
appeared  first  in  the  memory  parts,  and  later  in  the  more  complex  and  less  regularly 
connected  logic  devices.  A  second  reason  is  that  memory  devices  contain  such  a  high 
degree  of  image  repeatability  that  they  are  much  easier  to  test  for  lithographic  mistakes. 

Random  access  memories  have  for  a  long  time  been  divided  into  two  main  t3q)es: 
dynamic  and  static.  There  are  other  types  (e.g.,  nonvolatile),  but  these  two  categories 
predominate.  In  dynamic  memories,  charge  is  gated  onto  or  off  of  a  capacitor,  and  the 
resulting  potential  represents  either  a  one  or  a  zero.  Since  neither  the  gate  transistor  nor 
the  capacitor  is  perfect,  some  charge  leaks,  and  eventually  it  is  impossible  to  determine 
what  state  was  supposed  to  be  represented.  To  overcome  this  problem,  present  dynamic 
RAMs  (or  DRAMS)  have  circuits  built  in  which  periodically  r^  each  memory  location 
and  then  rewrite  it  in  a  process  called  refresh,  ^ile  refresh  is  going  on,  the  memory 
location  being  refreshed  is  unavailable  for  use.  Thus,  in  a  high  performance  system, 
DRAMs  cause  unplanned  for  wait  states  and  are  avoided.  On  the  other  hand,  for  non¬ 
time  critical  memory,  DRAMs  are  used  heavily  because  they  are  much  cheaper  and  have 
mere  memory  bits  per  single  chip  die. 

For  static  RAMs  (SRAMs),  the  second  predominate  memory  type,  the  one  or 
zero  state  is  stored  by  creating  a  bistable  multi  vibrator.  Since  this  circuit  usually  requires 
six  transistors  per  memory  bit,  SRAMs  take  up  more  room  on  chip.  On  the  oAer  hand. 
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each  state  is  stable,  and  no  refresh  is  required,  which  means  that  the  time  to  access  any 
given  bit  is  a  constant  number  of  clock  cycles.  SRAMs  have  an  ad^tional  advantage  in 
&at  they  are  usually  more  immune  to  system  noise,  a  particularly  important  feamre  in 
time  or  result  critical  systems.  They  also  tend  to  be  more  resistant  to  instantaneous 
radiation  upset,  since  the  charge  produced  by  a  passing  particle  is  more  likely  to  alter  the 
amount  of  charge  stored  than  to  cause  a  multi  vibrator  to  change  states. 

For  various  technology  reasons,  the  SRAM  is  usually  faster  than  the  DRAM, 
while  the  DRAM  has  higher  levels  of  integration.  At  present,  16  Meg  DRAMS  with  50 
nsec  access  time  are  just  becoming  available,  and  there  are  claims  that  4  Meg  SRAMs 
with  10  nsec  access  time  can  be  purchased.  Actually,  in  large  quantities  one  can  get  4 
Meg  DRAMs  and  1  Meg  SRAMs.  the  end  of  1994, 64  Meg  DRAMs  at  40  nsec  and 
16  Meg  SRAMs  at  perhaps  S  nsec  will  become  available.  Beyond  that,  there  is  some 
question  as  to  whether  it  wl  be  more  cost  effective  to  make  large  single  die  chips  or  go 
to  multi-chip  modules  (MCMs)  which  contain  several  die  each. 

There  may  be  problems  with  attempting  to  produce  memory  chips  having 
lithographic  features  much  below  0.35  microns  (|im).  Present  technology  is  in  the  0.8 
pm  to  0.5  |jun  range  for  aggressive  producers.  Since  the  area  of  a  die  is  approximately 
proportional  to  the  square  of  the  line  widths  used,  cutting  line  width  in  half  usually 
reduces  the  size  by  a  factor  of  four,  and  eventually  (as  the  density  of  defects  on  a  wafer 
decreases)  leads  to  four  times  as  much  logic  or  memory  per  chip.  In  addition,  as  defect 
densities  drop,  the  manufacturers  usually  go  to  larger  areas  per  chip.  . 

For  memories  in  panicular,  the  repetitiveness  of  the  design  makes  creating  die 
with  spare  parts  built  into  the  die  much  easier.  This  allows  the  designer  to  use  a  larger 
numbCT  of  viable  transistors  in  a  memory  chip  than  in  a  logic  part.  And,  since  memory  is 
so  ubiquitous  in  its  use,  it  will  continue  to  have  large  markets  and  be  favored  by  the  chip 
manufaemrers  for  their  future  investment.  Even  as  diminishing  returns  set  in  for 
lithography,  the  size  and  usability  will  continue  to  improve,  making  older  memo^  parts 
quickly  obsolete  and  harder  to  locate  for  sparing.  On  the  other  hand,  tlie  simplicity  of 
memory  devices  makes  it  a  much  easier  part  to  retrofit  in  a  system,  so  memories  should 
not  create  an  obsolete  parts  problem  for  future  systems  unless  chip  architectures  changes 
provide  for  much  less  noise  and  power  margin. 

An  important  development  is  the  move  to  put  substantial  memory  caches  on  the 
same  chip  with  the  logic  in  a  three  level  n^mory  scheme,  and  putting  SRAM  caches 
directly  on  large  DRAMs  to  make  them  look  more  like  SRAMs.  But  these  arc  just 
cosmetic  in  nature:  the  way  in  which  information  is  retrieved  from  memory  remains  the 
same.  A  large  number  of  lines  (one  line  for  every  power-of-two  number  of  memory 
cells)  are  required  to  access  a  memory  by  single  location. 

A  more  fundamental  change  in  memory  technology  will  be  the  move  to  "smart 
memories",  where  the  processor  asks  for  a  piece  of  data  by  name  rather  than  by  location. 
Since  many  pieces  of  data  take  up  more  than  one  location,  this  change  will  allow  a 
decrease  in  the  number  of  address  lines  required  to  access  a  memory,  as  well  as  allowing 
for  immediate  off  loading  of  many  simpler  direct  data  operations. 

With  all  the  changes  coming  in  the  future,  many  of  them  as  yet  unforeseen,  and 
the  increasing  size  and  complexity  of  systems  enabled  by  the  memory  market,  the  only 
way  to  maintain  a  system  in  the  future  will  be  to  maintain  an  accurate  simulation  of  the 
system  wherein  one  can  try  out  changes  and  determine  the  effects  of  changing  parts.  This 
will  be  a  necessity  because  the  total  life  cycle  of  a  large  system  is  numy  times  greater 
than  the  lifetime  availability  of  the  parts  it  contains.  Thus,  as  each  part  or  group  of  parts 
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become  either  unavailable  or  uneconomic  to  purchase,  adequate  substitutes  will  have  to 
be  determined  through  modeling  in  order  to  take  into  account  the  entire  range  of  variables 
in  the  manufactured  parts.  This  variability  is  the  key  factor  in  determining  if  a  part  is 
adequate,  but  it  is  too  di:^icult  in  practice  to  physically  try  out  all  the  combinations  which 
can  (and  will)  occur  when  the  parts  are  introduced  into  the  actual  system.  The  ability  to 
do  this  simulation  cost  effectively  probably  mandates  the  use  of  IEEE- 1076  as  the 
simulation  and  description  language  for  digital  systems. 


7*23  Gate  Array  Technology 

For  parts  which  are  to  be  built  in  smaller  quantldes,  designers  presently  use  gate 
arrays.  These  are  arrays  of  gates  which  art  all  made  identically,  but  are  not  connected.  A 
designer  just  does  one  layer  of  the  design,  the  one  that  connects  the  gates  together,  and 
the  manufacturer  takes  some  arrays  out  of  stock,  does  the  last  layer,  rests,  packages,  and 
delivers  the  array.  However,  there  is  another  technology  which  is  rapidly  catching  up 
with  gate  arrays,  the  so  called  field  programmable  gate' arrays.  These  arc  completely 
fabricated  and  packaged,  and  one  electrically  programs  the  necessary  interconnects  to 
produce  the  desired  part.  Of  course  they  fue  not  as  tightly  packed  as  a  custom  part,  but 
they  can  be  programmed  and  tested  in  a  couple  of  hours  instead  of  the  six  months  it  takes 
to  produce  a  fully  custom  part. 

It  is  with  these  parts  that  the  computer  tools  will  really  make  a  difference.  Soon, 
the  designer  will  create  a  mathematical  design,  and  the  tools  partition  the  design  onto 
FPGAs,  program  them,  and  program  circuit  l^ards  tc  accept  the  programmed  parts.  It 
will  be  possible  to  build  high  level  systems  containing  many  millions  of  gates  of  logic  in 
a  few  weeks.  At  the  same  time,  the  computers  will  be  able  to  calculate  all  the  "illities'' 
for  each  design.  These  calculations  are  not  difficult  conceptually  —  they  just  require  an 
enormous  amount  of  labor.  Using  the  tools,  systems  will  no  longer  require  replacement 
when  parts  become  unavailable.  Using  the  design  from  the  system's  documentation  base, 
replacement  parts  will  be  designed  whenever  necessary,  and  will  be  readily  available. 

At  the  same  time,  designs  will  become  much  more  robust.  Designers  now  only 
have  the  time  to  go  through  a  very  limited  set  of  tradeoffs,  and  they  have  to  accept  the 
first  design  which  meets  the  design  goals.  With  the  improved  tools  which  will  soon  be 
available,  designers  will  be  able  to  examine  hundreds  of  designs  and  pick  much  more 
optimum  solutions.  This  ability  to  optimize  the  design  will  go  a  long  way  to  alleviate  the 
inefficiencies  caused  by  using  non-custom  parts.  The  software  to  control  the  system  will 
be  designed  at  the  same  time  the  parts  are,  and  will  be  run  on  very  accurate  computer 
simulations  while  the  system  is  being  built.  It  will  be  possible  to  debug  the  software  and 
the  hardware  concurrently  before  the  system  is  ever  built.  And  dl  this  should  be 
available  by  the  year  2(XX)  at  the  latest. 


7*2.4  Analog-to-Digital  Converters 

An  area  of  technology  that  is  important  to  the  future  of  avionics,  especially 
tactical  sensors,  is  analog-to-^gital  (A/D)  and  digital-to-  analog  (D/A)  converters.  The 
A/D  converter  is  a  device  or  circuit  that  examines  an  analog  voltage  or  current  and 
converts  it  to  a  proportional  binary  number  that  can  be  input  to  a  computer.  The  D/A 
converter  is  the  inverse  of  the  A/D,  i.e.,  it  converts  a  binaiy  number  to  a  proportional 
analog  voltage  or  current.  As  these  converters  become  faster,  there  will  be  decrease  in  the 
dependence  of  avionics  on  analog  components.  The  PAVE  PACE  final  report  states  that 
Gallium  Aisemdc  (GaAs)  20  bit,  10  Gbit/second  A/D  will  begin  to  emerge  in  1997  and 
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be  mature  beyond  2001.  The  D/A  will  probably  lead  A/D  by  approximatelj  18  months 
(many  A/D  designs  incorporate  an  embedded  D/A). 


7-3  Microwave/Millimeter-wave  Monolithic  Integrated  Circuit 
(MIMIC) 

The  MIMIC  program  is  a  seven  year  DARPA/I'ri-Scrvice  defense  technology 
initiative  to  develop  and  demonstrate  affordable  and  available  MIMIC  chips  for 
application  to  radar,  electronic  warfare  (£W),  communications  and  smart  weapons 
systems.  Many  people  confuse  the  intent  of  the  MIMIC  Program  with  that  of  the  Very 
High  Speed  Integrated  Circuit  (VHSIC)  Program,  a  similar  defense  technology  initiative 
conducted  during  the  first  half  of  the  1980s  to  counter  the  erosion  of  the  US  lead  in 
silicon  based  digital  integrated  circuits.  Unlike  VHSIC,  which  was  designed  to  push 
digital  integrated  circuit  technology,  the  MIMIC  Program  was  initiated  when  it  became 
clear  to  defense  acquisition  managers  that  systems  based  on  an  emerging  Gallium 
Arsenide  (GaAs)  analog  integrated  circuit  technology  capable  of  operation  at  microwave 
and  millimeter-wave  frequencies,  were  generally  too  expensive  to  procure.  While  the 
Demonstration  and  Validation  (DEM-VAL)  models  of  these  systems  indicated  that 
advanced  levels  of  performance  could  be  achieved,  the  risk  and  cost  of  putting  them  in 
production  was  considered  unacceptable  due  to  the  inability  of  the  limited  number  of 
relatively  small  GaAs  Microwave/Millimeter-wave  Integrated  Circuit  (MMIC)  foundries 
to  pi^uce  chips  with  a  reasonable  yield.  This  problem  was  further  exacerbated  by  the 
inability  of  designers  to  design  a  working  and  yieldable  MMIC  without  many  design 
passes  due  to  the  inadequacy  of  good  device  and  circuit  models  as  well  as  computer  aid^ 
design  (CAD)  tools. 

Like  the  VHSIC  Program  which  preceded  it,  the  MIMIC  Program  is  comprised  of 
tour  major  program  phases.  There  were  sixteen  Phase  0  concept  study  contractor  teams 
representing  forty-eight  companies.  Phase  0  was  designed  to  lead  into  two  consecutive 
program  phases.  Phases  1  and  2.  These  are  the  program  phases  during  which  the  bulk  of 
MIMC  technology  development  and  demonstration  is  occurring.  Work  in  Phase  1  was 
conducted  ^m  May  1988  through  May  1991  by  four  contractor  teams  led  by  the 
following:  a.)  Hughes/GE;  b.)  ITT/Martin  Marietta  Joint  Venture;  c.)  the  Raytheon/TI 
MIMIC  Joint  Venture;  and,  d.)  TRW.  Work  in  Phase  1  included  materials,  devices, 
modeling,  design  tools,  circuits,  process  line  validation,  data  base  establishment,  qutdity 
and  reliability  evaluation  and  bra^board  demonstrations. 

Three  year  Phase  2  contracts  were  awarded  in  August  1991  to  the  Hughes/GE 
team,  the  Ra>^eon/n  MIMIC  Joint  Venture  team  and  the  TRW  team.  Work  in  Phase  2 
includes  continuing  the  technology  developments  begun  during  Phase  1,  developing  and 
demonstrating  advanced  technolo^es  (e.g.,  multi-function  chips,  more  efficient  devices, 
additional  millimeter-wave  chips,  etc.)  and  more  brassboard  demonstrations.  Finally, 
Phase  3  of  the  MIMIC  Program  runs  concurrently  with  Phases  1  and  2  and  is  structured 
to  support  smaller  development  efforts  which,  if  successful,  could  have  a  i^sitive  impact 
on  the  Phase  1  and  2  major  initiatives.  Work  in  Phase  3  includes  high  frequency 
microwave  and  millimeter-wave  test  probes,  new  materials  growth  and  epitaxy 
technology,  advanced  packaging  techniques,  advanced  device  and  circuit  models, 
computer-aided-design  tools,  reliability  and  radiation  tolerance  evaluation,  and  others. 
All  three  services  and  the  MIMIC  contractors  are  working  toward  the  eventual 
development  of  a  MIMIC  Hardware  Description  Language  (MHDL)  to  simplify  the 
process  of  specifying  new  chip  designs  to  foundries,  and  to  assure  inter  operability  of 
components  from  different  designers  and  foundries. 
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Although  modeled  after  the  VHSIC  Program,  the  MIMIC  Program  has  benefited 
from  lessons  learned  during  that  program.  VHSIC  was  successful  in  moving  the  digital 
integrated  circuits  technology  forward  at  an  accelerated  pace;  however,  many  of  the 
VHSIC  foundries  did  not  succeed  after  the  conclusion  of  the  program  due  largely  to  a 
lack  of  orders  for  VHSIC  parts.  This  situadon  resulted,  in  part,  from  the  guidance  behind 
the  VHSIC  contract  efforts  which  emphasized  generic  chips  which,  as  it  turned  out,  had 
almost  no  market.  Fortunately,  the  strong  commercial  interest  in  pursuing  digital 
technology  quickly  provided  a  home  for  the  flow  of  technology  develop^  under  VHSIC 
to  other  vendors  mostly  in  the  form  of  Application  Specific  Integrated  Circuits  (ASIC's) 
and  memory  chips.  Unlike  VHSIC  technology,  which  has  an  almost  infinite  commercial 
market  that  dw^s  the  military  market,  MIMC  technology  does  not  presently  enjoy  a 
large  commercial  market  and  must  be  focused  on  as  many  real  milita^  applications  as 
possible.  This  focus  has  been  the  guiding  principle  from  the  beginning  of  the  MIMIC 
Program  in  order  to  assure  a  market  for  the  resulting  MIMIC  chips.  Many  of  the  basic 
requirements  associated  with  military  applications  of  MIMIC'S  (e.g.,  wide  bandwidth, 
high  power,  etc.)  are  counter  to  most  commercial  requirements  governed  by  FCC 
regulations  (e.g.,  narrow  band,  low  power,  etc.). 

The  MIMIC  Program  requires  each  contractor  team  to  develop  and  update  a 
business  plan  to  help  forecast  market  opportunities  and  to  guide  program  developments. 
In  addition,  MIMIC  contractors  are  encouraged  to  focus  &eir  chip  designs  on  specific 
application  oppoitunities  to  help  assure  a  market  for  the  resulting  pr^ucts. 

The  VHSIC  management  and  execution  model  was  carried  forward  to  the  MIMIC 
Program.  The  services  take  turns  acting  as  the  coordinating  service  for  planning  a  tri¬ 
service  MIMIC  procurement,  then  all  thm  services  award  contracts  against  these  various 
solicitations  once  they  are  approved  by  DARPA.  Each  service  is  responsible  for  the 
award  and  execution  of  the  contracts  assigned  to  it  (e.g.,  the  Navy  was  assigned 
Raytheon/n  MIMIC  JV  for  Phases  1  &  2,  the  Air  Force  was  assigned  Hughes-GE  for 
Phases  1&  2,  and  the  Army  was  assigned  the  ITT/Martin  Marietta  JV  for  Phase  1  and 
TRW  for  Phases  1  &  2).  /J1  services  and  DARPA  participate  in  monitoring  all  contract 
efforts.  Each  MIMIC  Phase  1  &  2  contract  includes  chips  and  brassboard  demonstrators 
for  all  three  services  even  though  each  service  has  indicated  different  applications  of 
preference  (e.g.,  wide  band  &  EW-  Navy,  active  array  radar-  Air  Force,  and  millimeter- 
wave  sensors-Aimy). 


7-3.1  MIMIC  Phase  1  Accomplishments 

The  four  contractor  teams  who  performed  under  MIMIC  Phase  1  contracts  were 
highly  successful  in  achieving  validated  process  lines  for  the  manufacture  of  MIMIC 
chips.  Eighty-four  different  chip  designs  were  processed  and  thousands  of  chips  were 
delivered  for  further  evaluation.  Raytheon/TI  MIMIC  JV  and  Hughes/GE  both 
demonstrated  transfer  of  chip  designs  between  foundries  and  that  these  designs  can  be 
used  to  process  functionally  equiv^ent  MIMlC's.  All  Phase  1  contractors  demonstrated 
several  brassboard  insertions  of  MIMIC  chips  and  modules.  For  example  Raytheon/TI 
MIMIC  JV  demonstrated  MIMIC  Phase  1  chips  in  their  EW  Active  Array  brassboard  and 
the  Generic  Decoy  (GEN-X).  In  some  cases  MIMIC  served  as  an  enabling  technology 
such  as  in  seekers  for  the  Advanced  Anti-Aircraft  Missile,  EW  Active  Array  brassboard, 
and  SADARM  while,  in  other  cases,  MIMIC  reduced  costs  such  as  the  HARM  missile, 
GEN-X,  and  ASPJ,  Table  7-3.1  below  describes  examples  of  MIMIC  Phase  1  chips  and 
their  applications. 
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Table  7-3.1  Examples  of  MIMIC  Phase  1  Accomplishments 


CONTRACTOR 

CRIP  TYPES 

APPLICATIONS 

EW 

Raytheon/Tl  JV 

Wideband  LNA's, 

Wideband  Power 
Amplifiers,  Phase 
Shifter,  Switches 

GEN-X  Decoy,  STRAP, 

Towed  Decoys,  ESM, 

EW  Active  Array 
Brassboard,  Jammers 

ITT/Martin 
Marietta  JV 

Amplifiers,  Phase 
Shifters, Convert¬ 
ers,  Attenuators, 
Oscillators 

ASPJ  £  other  jammers, 
ALQ-136,  £  Decoys 

TRW 

Tuners,  Switches 

Mixers,  Receiver 
and  Amplifiers 

Chaneliized  Receiver 
Brassboard  to  Inqprove 
AM/SLQ-32  and  ESM 

RADAR 

Raytheon/TI  JV 

LNA's,  Power 

Amplifiers, 

Digital  Attenuator 

C,X,  £  Ku-band 

Active  Array  Radars 
and  Shared  Aperture 

Hughes /GE 

LNA's,  Attenuators 
Amplifiers,  Phase 
Shifters,  Switches 

C-band  £  X-band 

Active  Array 

CNI 

Raythoon/TI  JV 

Ka-band  LNA 

St  Down  Converter 

HILSTAR 

ITT/Martin 
Marietta  JV 

C-band  Multi¬ 
function  T/R 

Chip,  Amplifiers 

VCO ' s ,  Converters 

Combat  Engagement 
Capability  (CEO, 

SHF  SATCOM 

Hughes/GE 

LNA's,  Phase  Shifter, 
Mixer,  Oscillator 

GPS  Antenna-: 

Electronics 

SMART 

WEAPON 

Raytheon/TI  JV 

Ka-band  LNA, 

Q-band  VCO  and 

Power  Anqslifier 

Missile  Seeker 

SADARM 

Hughe /GE 

Ka-band  LNA  and 

Power  Anqplifiers 

Mixer,  Limiter  t  VCO 

Advanced  Milimeter- 
-wave  Missile  Seeker 

ITT/Martin 
Marietta  JV 

Milimeter-wave 

Receiver 

SADARM,  MLRS  TGW, 

Longbow 

TRW 

FM-CW  Transceiver, 
Milimeter-wave  IC's 

Multioption  Fuze  for 
Artillery,  SADARM 
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7-3 MIMIC  Phase  2  Directions 

The  MIMIC  Phase  2  Program  is  comprised  of  three  contracts  —  one  each  managed 
by  the  Army,  Navy  and  Air  Force--  to  further  the  achievements  of  previous  Phase  1  and  3 
efforts.  The  broad  objectives  of  Phase  2  include:  a.)  continued  cost  reduction  for  a  given 
RF  function;  b.)  continued  reliability  and  quality  improvement  leading  to  eventual 
Qualified  Manufacturers  List  (QML)  approval;  c.)  validation  of  new  processes;  d.) 
advanced  devices  and  technologies;  and,  e.)  additional  MIMIC  insertions  and 
demonstrations.  The  brassboard  and  module  demonstrators  will  again  have  application  to 
EW,  radar,  communications  and  smart  weapons. 

The  Navy  is  directing  the  Raytheon/TI  MIMIC  Joint  Venture  MIMIC  Phase  2 
Program  team  which  includes  Lockheed  Sanders,  Teledyne,  Hittite,  General  Dynamics 
(Ft.  Worth)(now  Lockheed),  Aerojet,  Airtron  and  Consilium.  Work  includes  more 
complex  and  compacted  chips,  shrinking  the  dimensions  of  the  Phase  1  Metal- 
Semiconductor  Field  Effect  Transistor  (MESFET)  technology  from  0.5  |.to  to  0.25  pm, 
validating  several  new  MIMIC  processes,,  new  devices,  better  materials,  advanced 
packaging  technology,  four  brassboard  demonstrations  and  eight  chip/module 
demonstrators,  llie  Rayfoeon/Texas  Instruments  team  is  developing  28  new  chips  which 
address  the  needs  of  at  least  forty  identified  applications.  The  p^onnance  of  these  chips 
are  beyond  the  Phase  1  levels  of  performance.  Yield  and  cost  goals  for  these  chips  are 
also  beyond  those  of  Phase  1.  Eleven  of  the  28  Phase  2  chips  are  power  amplifier  chips. 
The  goals  for  these  Phase  2  power  amplifier  chips  exceed  the  results  achieved  in  Phase  1. 
Phase  2  power  amplifier  chips  require  a  different  process  than  those  used  in  Phase  1. 

The  Raytheon/Texas  Instruments  JV  team  is  developing  Heterojunction  Field 
Effect  Transistor  (HraT)  and  Heterojunction  Bipolar  Transistor  (HBT)  processes  in 
Phase  2.  These  processes  were  not  required  to  meet  the  Phase  1  program  requirements. 
The  goal  for  HreT  power  added  efficiency  is  48%  at  18  GHz.  The  goal  for  HBT  power 
added  efficiency  is  55%  at  X-band.  Both  of  these  goals  are  far  in  excess  of  the  15%  Phase 
1  result.  The  noise  figure  goal  for  the  team's  0.25  pm  ion  implanted  low  noise  process  is 
1.7  dB  compared  to  5.5  dB  at  the  end  of  Phase  1.  One  aspect  of  the  MIMIC  program  is 
typified  by  chip  cost  and  yield  improvement  goals  established  prior  to  Phase  1  for 
MIMIC  chips  as  a  function  of  time.  Mor  to  Phase  1,  overall  yield  for  standard  processes 
was  approximately  10%  and  the  cost  per  square  millimeter  of  chip  area  was 
approximately  $20.  The  Phase  1  goal  was  25%  yield  and  $2  per  square  millimeter.  The 
goal  for  Phase  2  was  established  at  40%  yield  and  $0.80  per  square  millimeter,  while 
transitioning  from  3"  wafers  to  4"  wafers.  Based  on  Phase  1  results,  these  earlier 
projections  are  still  valid  and  in  some  cases  yield  numbers  have  already  exceeded  the 
Phase  2  projections.  However,  cost  is  still  heavily  driven  by  volume  considerations  and 
will  continue  to  be  dependent  on  the  realization  of  business  according  to  market 
projections. 

At  the  same  time,  the  functionality  of  the  chips  under  development  is  doubling 
every  couple  of  years.  For  example,  prior  to  Phase  1  typical  amplifiers  had  one  or  two 
stages  of  gain.  During  Phase  1,  t]^ic^  amplifiers  had  tluee  stages  of  gain.  During  Phase 
2,  amplifiers  will  have  four  or  in  some  cases  Hve  stages  of  gain,  as  well  as  having 
ai^tional  circuitry  such  as  switches  built  into  the  same  chip. 

The  performance  is  also  continuously  improving  over  time.  During  the  Phase  1 
time  frame  the  power  added  efficiency  goal  for  a  wideband  (C-X-Ku-Band)  power 
amplifier  was  15%.  The  Phase  2  goal  for  an  amplifier  covering  the  same  frequency  l^d 
is  25%  and  the  power  produced  is  4  times  that  of  the  Phase  1  chip.  These  system  driven 
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performance  requirements  are  driving  the  team  to  develop  and  validate  new  processes  in 
Phase  2  that  can  support  the  improved  performance. 

In  addition  to  cost,  yield,  complexity  and  performance  advances,  the  Phase  2 
program  will  develop  28  chip  designs  to  insert  variously  into  F-22  EW  Array,  Advanced 
Multimode  Missile  (AMMM)  seeker,  Anti-Air  Warfare  (AAW)  Subarray  for  ships. 
Airborne  Shared  Aperture  Program  (ASAP),  High  Performance  Armament  System 
(HIPAS)/M734  Fuze,  MDOT  decoy,  F-22  Avionics,  Man  Portable  Radar  (P-STAR), 
Microwave  Landing  system  (MLS),  F-22  T/R  Module,  Advanced  Airborne  Electronic 
Decoy/  Integrated  Solid  State  Module  (AAED/ISSM),  Sparrow  Missile,  and  Advanced 
AAW  T/R  Module.  Phase  2  also  includes  several  enhancements  to  applications  initiated 
during  the  Phase  1  program  such  as  GEN-X,  AMRAAM,  Seek  and  Destroy  Armor 
(SADARM),  Micro-TWT  Driver  Module,  and  STRAP.  By  comparison,  during  Phase  1 
the  team  developed  fourteen  chips  designs  to  insert  into  six  hardware  demonstrations. 

The  TRW  team,  which  includes  Westinghouse,  General  Dynamics,  Alliant 
Techsystems,  and  Hercules,  under  direction  of  the  Army,  is  developing  and  validating 
sevwnl  new  technologies  including:  a.)  a  3  ^im  HBT  process  for  VCO  and  VCO/mixer 
applications  to  achieve  low  phase  noise;  b.)  a  0.2  pm  HEMT  process  for  a  wide  range  of 
mixer,  convener  and  low  noise  amplifier  brassboards  to  achieve  high  gain  at  low  noise 
over  wide  bandwidth;  c.)  a  0.1  pm  HEMT  process  for  W-band  transceiver  and  receiver 
brassboards  to  achieve  a  three-stage  amplifljr,  image  reject  mixer,  monolithic  detector 
and  voltage  controlled  oscillator,  d.)  a  0.2  pm  Power  HEMT  process  for  amplifiers;  and, 
e.)  a  0.5  pm  PFET  process  for  use  as  RF  down  conveners,  mixers,  phase  shifters,  and 
power  ampliriers. 

TRW  is  developing  an  integrated  electronic  warfare  (EW)  receiver  brassboard. 
The  primary  insertion  candidate  for  that  product  is  the  Aircrait  Survivability  Equipment 
(ASE)  Radar  Warning  Receiver  aboard  the  RAH-66  Gomanche  helicopter,  fhe  secondary 
insertion  candidate  is  the  Special  Threat  Analysis  and  Recognition  (STAR)  receiver 
system,  which  has  multiple  airborne  applications  including  potential  for  integration  with 
any  radar  warning  receiver.  The  brassboard  consists  of  three  Integrated  Microwave 
Assemblies  (IMA's),  a  block  frequency  converter,  a  single  conversion  tuner,  and  a  dual 
conversion  tuner.  A  total  of  five  chips  wUl  be  developed.  TRW  is  also  developing 
millimeter  wave  low  noise  amplifier  and  mUtimeter  wave  oscillator  chips  using  PHEMT 
technology  that  can  be  inserted  into  the  ALR-67  ASR  Millimeter  Wave  Receiver 
(MMWR).  Other  applications  include  wideband  T/R  module  for  Airborne  Shared 
Aperture  Program,  X-band  transmit  modules  for  radiar,  W-band  receiver  for  Multiple 
Launch  Rocket  System,  W-band  Transceiver  for  X-Rod,  broad  band  receiver  for  missile 
seekers,  EHF  data  link  transceiver  for  EHF  SATCOM,  and  Q-band  transceiver  for 
SADARM. 

The  Air  Force  is  directing  the  Hughes/GE  (now  Martin  Marietta)  MIMIC  Phase  2 
Program  team  (which  includes  AT&T,  Litton,  Rockwell  International,  M/A-COM, 
Alliant  Techsystems,  EEsof  and  Cascade  Microtech).  The  Hughes/GE  team  is  developing 
and  validating  several  processes  including:  a.)  continuation  of  the  signal  and  power 
MESFET  process  work  begun  during  Phase  1;  b.)  a  0.25  pm  Pseudomoiphic  High 
Electron  Mobility  Transistor  (PHEMT)  processes  for  several  fr^uency  ranges  U)  improve 
performance  of  ampliriers,  VCOs  and  mixers;  and,  c.)  HBT  process  for  high  power 
amplifiers  at  X-band. 

The  brassboard  demonstrations  of  the  Hughes/GE  team  include:  a.)  X-band  T/R 
modules  for  an  active  array  radar  brassboard;  b.)  receivei  and  transmitter  modules  for  a 
Smart  Target  Activated  Fire  and  Forget  (STAFIO  Brassboard;  c.)  low  noise  and  power 
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amplifier  modules  for  Single  Channel  Advanced  Man  Portable  Terminal  (SCAMP);  and 
d.)  low  noise  and  power  amplifiers  for  the  Ground  Based  Interceptor  (GBI) 
Communications  System. 


7-33  Tri-Service  MIMIC  Reliability  And  Radiation  Effects  Program. 

Begun  during  MIMIC  Phase  1,  the  objective  of  this  program  is  to  target  specific 
reliability  areas  of  critical  importance  to  the  services.  The  goal  is  to  ensure  with  a  high 
de^e  of  confidence  that  the  MIMIC  chips  meet,  or  can  be  made  to  meet,  system 
reliability  specifications.  An  important  aspect  of  tliis  objective  is  to  promote  insertion  of 
MIMIC  technology,  leading  to  enhanced  military  capabilities.  Through  a  closely 
integrated  reliability  program,  the  services  can  determine  the  resultant  effects  of  material, 
design,  fabrication  processes,  assembly,  and  packaging  on  the  chips  and  modules 
developed  under  the  MIMIC  l^ogram.  TTic  service  laboratories  working  on  this  eff'>rt 
include  primarily  the  U.S.  Navy  Naval  Research  Laboratory  (NRL),  US  ^my  Laboratory 
Command  (LABCOM),  and  the  U.S.  Air  Force  Rome  Laboratory  (RL)  and  Wright 
Laboratory  (WL). 

The  tri-service  MIMIC  Reliability  and  Radiation  Effects  Program  closely 
coordinates  the  reliability  activities  of  the  three  Services  on  the  MIMIC  Program  and 
assigns  responsibilities  based  on  expertise,  work  load,  unique  Service  need  and  Service 
unique  capabilities.  Under  the  MIMIC  Phase  2  program  the  3  contractor  teams  v«dll  have 
a  total  of  10  foundries  covering  21  GaAs  processes  including  Field-^ect  Transistors 
(FETs),  High  Electron  Mobility  Transistors  (HEMTs)  and  Heterojunction  Bipolar 
Transistors  (HBTs).  From  these  foundries  four  types  of  Standard  Evaluation  Circuits 
(SECs)  from  each  team  will  be  delivered.  The  four  basic  types  of  SECs  will  be  : 
microwave  Power  Amplifier  (PA),  microwave  HBT  PA,  microwave  Low  Noise 
Amplifier  (LNA),  and  a  millimeter-wave  LNA.  A  common  SEC  carrier  will  be  q)ecified 
by  DARPA,  one  type  for  microwave  and  one  type  for  millimeter  wave. 

The  approach  consists  of  a  coordinated  Tri-Service  effort  organized  to  efficiently 
accomplish  the  program  objectives.  Each  Service  will  assume  a  number  of  "prime" 
responsibilities  that  are  centered  around  eight  key  thrusts.  This  division  of 
res^nsibilities  provides  each  service  with  specific  areas  to  focus  on,  and  in  the  aggregate 
provides  the  government  with  a  comprehensive  coverage  of  the  MIMIC  technology.  The 
Navy  will  focus  on  RF  life  testing  of  1  to  26  GHz  MlMICs.  It  will  test  both  low  noise  and 
power  SECs  and  will  be  nble  to  effectively  standardize  on  reliability  test  fixtures  and 
carriers.  In  a  similar  manner,  the  Army  will  focus  on  the  millimeter  wave  MIMIC  SECs 
and  be  able  to  standardize  fixtures  and  carriers  in  the  27  to  100  GHz  frequency  range. 
The  Army  will  also  evaluate  1  to  18  GHz  devices  applying  a  life  test  facility  developed  in 
Phase  1. 

The  Air  Force  will  focus  its  reliability  assessment  work  at  the  fabrication  process 
level  and  module  level.  Evaluation  of  MIMIC  test  structures  will  be  conducted.  The  RL 
work  will  be  closely  coupled  with  the  WL  materials/device  correlation  work  in  which 
contractor  High  Density  Test  Reticle  (HDTR)  data  are  evaluated  and  analyzed.  In 
addition,  reliability  life  test  of  module  level  MI^Cs  will  be  accomplished  through  the 
Air  Force.  The  trbservicc  reliability  assessment  work  will  be  supplemented  by  special 
area  evaluations  of  radiation  effects,  electrostatic  discharge  (ESD),  high  j^wer 
microwave  (HPM)  hardening,  thermal  analysis,  and  electrical  bias  and  RF  overstress 
testing.  Data  analysis  and  physics  of  failure  tasks  will  also  be  conducted. 
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To  date  the  Navy,  Air  Force,  and  Army  have  conducted  in-house  activities  in 
support  of  the  MIMIC  Reliability  and  Radiation  Effects  Program.  The  Navy  program, 
conducted  by  the  NRL,  centered  on  the  inspection  of  Phase  1  deliverables,  revising  the 
Tri-Service  Reliability  and  Radiation  Effects  Integration  Plan,  demonstration  of  the  EW 
brassboaid,  and  RF  life  testing.  Phase  1  deliverables  consisting  of  chips  on  carriers,  test 
fixtures,  rejports,  modules  and  brassboards  required  by  the  contract  have  been  rrccived 
and  visual  mspections  completed.  A  demonstration  of  the  EW  Inrassboaid  was  held  at  the 
NRL  anechoic  chamber  in  the  Tactical  Electronic  Warfare  division.  An  RF  life  test  of  the 
MIMIC  designated  element  circuit  function  (ECF)  was  completed  at  NRL. 

The  Air  Force  RL  program  concentrated  on  finite  element  thermal  modeling, 
reliability  life  testing  of  C-biuid  MIMICs,  test  structures  thermal  stressing,  QML,  product 
evaluation,  and  failuie  analysis.  Thermal  modeling  of  the  ECF  MIMIC  and  IR  thermal 
measurements  of  this  device  were  coordinated  by  RL  and  NRL.  Ten  C~band  power 
amplifiers  were  received  and  life  testing  was  initiated.  Thermal  stress  testing  of  test 
stPictures  was  carried  out  to  800  hours. 

The  Army  LABCOM  Reliability/Radiation  Effects  program  concentrated  on 
building  test  fixtures  for  RF  life  testing.  A  new  64  position  C-band  and  Ku-band  RF  life 
test  system  is  now  operational. 


7*3.4  MMIC  Section  Summaury 

Although  we  are  just  past  half  way  through  the  MIMIC  Program,  the  technology 
is  already  rinding  a  home  in  ji^uction  systems  (e.g.,  HARM,  GEN-X,  etc.),  and  MIMIC 
chips  were  found  in  some  of  the  systems  used  in  Desen  Storm.  During  Phase  1  there  were 
tens  of  thousands  of  chips  processed  and  hundreds  of  each  type  were  delivered  to  the 
Government  for  inspection  and  further  evaluation.  NUMIC  has  become  an  enabling 
technology  for  systems  such  as  the  F-22  radar,  EW  active  array  jammers,  advanced 
missile  seekers,  more  effective  armament  and  others.  MIMIC  has  also  demonstrated  it 
can  reduce  the  cost  of  systems  such  as  OEN-X  decoy,  ASPJ,  HARM,  etc. 

MIMIC  Phase  2  cribits  are  concentrating  on  further  increases  in  output  power, 
increased  efriciency,  wider  bandwidth,  lower  noise  figure,  increased  functionality,  on- 
wafer  test  of  power  circuits,  and  increased  yields  as  well  as  qualifying  new  prwesses. 
Statistical  process  control  of  the  manufacturing  process  is  expected  to  continue  to 
increase  the  yield  and  lower  the  cort  of  a  given  function.  Special  attrition  is  being  given 
to  improving  visual  yield  of  the  finish^  chips.  A  signincant  amount  of  progress  is 
expected  towards  achieving  QML  for  the  MD^C  foundries,  with  tqpproval  anticipated 
within  a  short  time  after  the  completion  of  Phase  2.  QML  approval  should  further  r^uce 
the  costs  associated  with  applying  MIMIC  technolof^.  The  number  of  brassboard 
demonstrations  is  increasing  as  are  the  number  of  defense  systems  planning  to  use 
MIMIC  technology. 

Many  of  the  MIMIC  foundries  are  experiencing  an  increased  interest  in  applying 
the  technology  to  comnriercial  applications  such  as  direct  satellite  broadcast,  cellular 
communications,  smart  highways,  automotive  sensors,  instrumentation,  wireless  local 
area  networks,  and  others.  Severd  of  these  foundries  are  already  under  contract  for 
components  for  both  dooMstic  and  foreign  markets.  These  markets  are  projected  to  grow 
substantiaUy  over  the  next  ten  years  which  will  hopefully  help  counter  &e  anticipated 
decrease  in  the  total  number  of  defense  applications  for  MBdlCs  in  die  same  time  frame. 
The  best  evidence  of  the  success  of  the  MMIC  Program  is  that  these  foundries  report  that 
they  are  viewed  as  highly  competitive  on  the  world  market.  This  situation  can  only 
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improve  further-as  MIMIC  Phase  2  progresses  and  should  serve  to  continue  the  reduction 
in  cost  of  parts  for  both  commercial  and  defense  sysr  ns. 


1-3S  Beyond  MMIC 

The  MIMIC  Program  has  been  a  major  success  story  in  demonstrating  more 
available  and  affordable  mici-owavc  and  millimeter  wave  integrated  circuits  and  it  is 
planned  to  use  MIMIC  as  the  model  for  several  other  defense  technologjr  thrusts.  Two 
areas  where  this  result  will  be  seen  in  the  near  future  is  microwave/millimeter-wave 
packaging  and  in  active  array  demonstradons.  MIMIC  concentrated  mostly  on  the  chip 
technology  and  design  tools  whereas  these  new  inidatives  will  concentrate  on  simplifying 
the  design,  fabricadon  and  testing  of  module  containing  these  chips  into  functional 
circuits  (e.g..  cransniit.  receive,  etc.)  for  both  military  and  commercial  markets.  Work 
will  include  new  housing  materials  and  concepts,  new  interconnect  concepts,  new  module 
level  computer-aided-design  tools,  new  thermal  management  techniques,  new  power 
regulation  and  distribution  concepts,  and  others.  These  effbrts  will  lead  to  using  concepts 
similar  to  the  multichip  module  techniques  used  in  digital  packaging  for  microwave 
modules.  It  is  foreseen  that  by  the  mid  1990s  transmit/reccive  modules  will  be  fabricated 
as  arrays  of  monolithic  modules,  using  novel  packaging  and  cooling  techniques,  with 
integral  radiators  and  high  density  power  suppUes  (e.g.,  ^  100  watts/cu.  in.  and  2;  90% 
efficient).  These  modules  wUl  bie  batch  fabneated  and  tested  using  highly  automated 
equipment  yielding  more  affordable  modules,  in  turn,  such  modules  will  permit  building 
active  array  radai,  receivers,  transmit  arrays,  wideband  shared  aperture  arrays,  etc.  which 
are  not  only  more  affordable  but  also  simpler  to  install  due  to  their  low  profile. 


7-4  Advanced  Processor  Technology 

7-4.1  Microprocessor  Technology 

Microprocessor  technology  is  presently  moving  along  two  courses  that  are 
represented  by  two  generic  types  of  device.  The  first  generic  type  is  the  Reduced 
Instruction  Set  Con^uter  (RISC)  architecture,  which  is  the  driver  behind  the  rash  of  very 
high  performance  workstations.  They  are  optimized  to  support  a  multi-task  management 
system  like  UNIX,  and  depend  on  the  compilers  to  support  the  less  used  but  more 
complex  tasks  while  being  optimized  for  the  simple  re^ster-to-register  operations. 
Normally  they  devote  as  much  chip  area  to  registers  as  possible.  They  also  depend 
heavily  on  caching  (moving  entire  blocks  of  memory  from  a  global  slow  memory  to  a  fast 
local  on-chip  memory)  and  on  uniform  program  flow.  The  uitiform  flow  is  neces«uy  in 
order  to  get  a  large  cache  hit  ratio  (i.e.,  ratio  of  the  number  of  words  found  locally  vs.  the 
number  called  for  by  the  processor).  This  type  of  processor  is  represented  by  the  Sun 
SPARC,  the  Intel  i960,  the  HP  PA,  and  the  DEC  Alpha.  The  Alpha  is  probably  the 
current  leader,  but  new  chips  appear  often  and  capability  is  growinjg  rapidly.  Also,  as 
lithography  (chip  making  technology)  improves  and  more  capability  is  available  on  chip, 
the  (Afferent  tyj^s  of  resources  are  begmning  to  increase.  Even  the  definition  of  RISC 
has  been  changed  to  mean  "single  cycle  instructions"  rather  than  the  original  "few  simple 
instructions". 

The  second  generic  type  of  microprocessor  is  the  Complex  Instruction  Set 
Computer  (CISC).  This  type  is  characterized  by  on-chip  hardware  to  provide  more 
complicated  hardware  and  software  operations.  CISC  processors  do  the  same  operations 
as  the  RISC  chips,  but  the  most  frequently  used  operations  (such  as  load,  store,  AND, 
OR,  NOR,  etc.)  are  not  performed  as  fast  because  of  complicated  checking  and  status 
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icigister  setting,  which  must  take  place.  As  such,  they  place  more  dependence  on  the 
hardware  than  on  the  software  compilers  to  support  operations.  These  chips  include  the 
Motorola  680XX,  the  Intel  80X86  series  used  in  personal  computers,  and  the  engines  for 
most  previous  generation  computers. 

A  third  class  of  processing  chip  which  is  not  usually  accorded  the  dtle  of 
microprocessor,  is  the  Digital  Signal  P>rocessing  (DSP)  chip.  This  chip  is  finding  a  niche 
as  the  embedded  processor  in  controllers,  and  as  the  arithmedc  prouesscr  in  signal 
processors  and  workstations.  It  is  characterized  by  two  things:  an  on-board  single-cycle 
Muldplier/Accumulator  (MAC),  and  extremely  e:Ricient  capability.  These  chips 
include  the  TI  TMS320(I!40,  the  AT&1‘  DSP32C,  the  Motorola  DSP96002,  the  Intel 
i860XP,  etc.  to  name  a  few.  There  arc  frequently  other  resources  available  on  the  DSP 
chip  such  as  DMA  controllers,  A/Ds,  and  D/As.  For  computationally  intensive  tasks  on 
large  data  blocks,  the  DSP  is  usually  orders  of  magnitude  faster  than  the  RISC  ^r  CISC 
approach.  On  the  other  hand,  software  of  a  level  higher  than  assembly  or  C  docs  not 
normally  map  well  onto  DSP  architectures.  — 

7-4,2  Examples  of  Commercial  RISC,  CISC  and  DSP  Chips 

In  this  section  there  is  information  on  representative  examples  of  the  RISC,  CISC 
and  DSP  chips. 


An  example  of  the  RISC  type  chip  is  the  Intel  i960  family.  This  family  of  32-bit 
processors  was,  according  to  Intel,  desired  especially  for  embedded  applications.  All 
members  of  the  series  share  a  common  core  architecture  (RISC  technology),  and  the  core 
functions  are  object  code  compatible.  Each  processor  in  the  series  has  a  different  set  of 
special  functions.  There  are  both  commercial  and  military  versions  available  -  for 
instance,  the  80960KB  (commercial,  floating  point)  and  the  80960MC  (Militoiy,  floating 
point)  have  identical  architectures,  and  nearly  identical  pin-outs  in  the  same  t^  of  pin 
grid  package.  The  main  difference  is  that  the  80960MC  has  a  military  temperature  range, 
and  reduced  specification.  For  instance,  the  MC  is  only  rated  to  20MHz  clock  and  7.5 
VAX  MIPS,  while  the  "KB"  is  rated  at  25MHz  and  7.5  VAX  I/IIPS.  The  core  80960 
appears  to  be  sixteen  32-bit  global  registers,  sixteen  32-lnt  local  registeii's,  and  at  least 
four  32-bit  control/pointer  registen.  It  also  includes  a  built  in  instruction  cache  (5 12- 
byte),  and  a  built  in  interrupt  controller  and  bus  logic  control.  Ihe  "KB"  and  "MC" 
contain  also  four  80-bit  floating  point  registers  and  a  built  in  floating  point  unit  capable  of 
5.2M  (4.0M  for  "MC")  Whetstones  at  full  clock,  doing  IEEE  754  floating  point 
operations.  Floating  point  add/subtract  takes  0.5/0/7  psec  for  32/64  bit  words;  multiply 
1.0/1. 8  psec,  32/64  bit  words;  divide  1.8/3.8  psec;  square  root  5.0/5.2  psec;  sine 
20.3/22.1  32/64  bit  words;  etc..  The  80960  series  uses  a  high  bandwidth  locd  bus. 

It  has  a  32  bit  multiplexed  address/data  path,  15  lines  for  control  of  address,  data,  and 
signal  lines,  and  two  bus  arbitration  lines.  It  has  a  four  word  burst  capability,  which 
allows  1  to  16  byte  transfer  operations,  and  43  Mbytes  of  sustained  rcad/write 
operations. 


For  an  example  of  the  CISC  architecture,  one  can  examine  the  Intel  80XX6  series 
(the  famous  "PC"  chip)  or  the  Motorola  68XXX  series.  These  chips  contain  such  items 
as  address  generators,  as  well  as  a  large  microcoded  instruction  set  The  Motorola  series 
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in  particular  contains  a  large  number  of  synunecric  addressing  schemes  which  allowed 
high  level  software  to  easily  address  memory.  Later  chips  in  the  series  have  on-board 
cache,  cache  controllers,  floating  point  coprocessors,  etc. 


An  example  of  the  DSP  is  represented  by  the  Texas  Instruments  (TI) 
TMS320XXX  senes.  In  pardcular  is  TI's  fourth  generation  DSP,  the  TMS320C40.  It 
features  high  speed  multiple  I/O  ports,  and  like  all  DSPs  is  optimized  for  the  multiply 
accumulate  (MAC)  signal  processing  function.  It  has  six  byte  wide  DMA  controlled 
concurrent  ports,  each  capable  of  20MBytes/sec  bi-directional  flow,  which  allows  a  large 
variety  of  multiprocessor  architectures  to  be  efficiently  implemented.  It  also  has  two 
identical  32-bit  buses  for  memory  and  or  data  access. 

Internally,  the  32()C40  conodns  a  full  32x32  MAC,  a  single  cycle  FPU  multiplier, 
and  support  for  single  cycle  external  memory  accesses.  It  will  also  perform  an  integer  to 
floating  point  conversion  in  a  single  cycle,  and  even  has  a  built-in  barrel  shifter.  It  has 
twenty-two  32  bit  registers,  and  twelve  40  bit  registers.  Instruction  cycle  is  40  nsec  at  50 
MHz  dork.  It  supports  automatic  module  and  bit  reverse  addressing.  It  supports  both 
IEBE-7S4  32  bit  as  well  as  a  40  bit  floating  point  format  Another  featurt  of  high  value 
to  signal  processing  and  to  real  time  processing  is  its  ability  to  respond  to  interrupt 
instructions. 

The  320C40  does  a  floating  point  MAC  in  40  nsec  at  50  MHz,  a  floating  point 
divide  in  360nsec.  It  can  do  eleven  operations  in  parallel,  and  has  an  instruction  set  of 
135  instructions.  It  does  not  have  an  auxiliary  memory  management  unit,  and  does  not 
run  an  operating  system  such  as  UNIX.  It  does  have  C  compilers  available,  and  should 
have  an  Ada  compiler  soon,  because  there  is  one  for  its  predecessor  chip  (the 
TMS320C30). 

Industry  respondents  addressed  the  issue  of  standard  instruction  sets  as  the  focus 
of  computer  policy.  Industry  opinion  is  that  evolution  toward  the  Application  Program 
Interface  (API)  to  be  the  most  effective  approach  to  standardization  instead  of  the 
assembly  language  Instruction  Set  Architecture  (ISA).  In  this  methodology,  standard 
operating  system  interfaces  and  software  linkage  procedures  for  input/output,  timers, 
diagnostics,  and  inteirupts  would  be  defined  instead  of  the  a.ssembly  language  interface. 
This  would  free  the  application  programmer  tiom  the  necessity  of  understanding  low 
level  hardware  features,  but  each  processor  type  would  require  a  unique  operating  system 
Implementation,  although  the  interfaces  would  be  standaiti.  The  API  approach,  if  fully 
implemented,  decouples  software  from  the  hardware  technology  obsolescence  issue,  so 
this  approach  offers  much  promise. 


7-43  Technology  T rends  and  Time  Lines. 

The  life  of  commercial  processors  can  be  gauged  by  an  Electrical  Engineering 
Times  article  (29  June  92)  which  states  that  Intel  80386  usage  will  decline  from  76.9% 
($620M)  in  1^1  to  45.1%  in  1996  (S403M).  The  80386  market  loss  will  be  replaced 
mostly  by  the  Intel  80486,  with  a  next  generation  product  predicted  to  acquire  7.5%  of 
the  nurket  in  1996. 

Gntphics  processing  is  another  area  of  opportunity.  Reuse  of  commercially 
developed  graphics  software  libraries  can  be  simplified  by  using  the  graphics  processor 
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for  which  such  software  was  written.  Although  there  is  sr^aie  movement  in  this  direction, 
additional  work  is  needed  to  prove  the  approach  and  minimize  risk  of  its  use. 

Finally,  although  not  stated  explicitly  by  the  industry  presenters,  it  is  clear  that  the 
DoD  must  find  some  way  to  leverage  th.e  tread  for  groups  of  companies  to  band  together 
for  product  development.  One  example  of  this  is  the  MIPS  R-4000  processor,  licensed  by 
MIPS  Inc.,  but  manufactured  and  developed  by  Integrated  Device  Technologies,  LSI 
Logic,  and  Performance  Semiconductor.  Another  example  is  the  SPARC  processor 
developed  by  Sun  Microsystems  in  conjunction  with  Bipolar  Integrated  Technology, 
Cypress  Semiconductors,  Fujitsu  Microelectronics,  LSI  I.ogic,  and  Texas  Instruments 
Semiconductors.  Just  as  airframe  manufacturers  are  pooling  efforts  on  new  aircraft 
designs,  commercial  processor  designs  will  become  joint  ventures  to  reduce  risk  and 
share  development  cost. 


7-4.4  Key  Developments  For  Advanced  Processing 

The  industry  briefs  contained  discussions  of  two  important  advanced  computer 
efforts;  Aladdin  and  Touchstone.  The  Aladdin  processor  is  an  advanced  signal  processing 
computer  made  by  Texas  Instruments  for  target  recognition  applications.  This  computer 
uses  the  R-4000  processor,  multiple  TMS320C30  signal  processors,  the  VME  System 
Bus  (VSB),  and  is  prog^imed  in  the  Ada  language.  Touchstone  is  a  DARPA  initiative 
for  supercomputer  applications.  Intel  is  building  a  commercial  computer  based  on  the 
Touchstone  architecture  u.<nng  Intel  i860  processors.  Honeywell  is  currently  prototyping  a 
militarized  version  of  this  system. 


lAAl _ Hewlett-Packard  Processor 

The  Hewlett-Packard  was  one  of  the  early  RISC  architectures,  originally 
introduced  by  HP  in  1986  as  the  Speettam  architecture.  It  has  a  register  based 
architecture,  32  bit  instruction  word,  simple  addressing  modes,  load/store  operations, 
simple  hard-wired  instructions,  and  no  full  integer  multiply  of  divide  instructions.  It  uses 
the  Harvard  architecture;  separate  data  and  instruction  paths.  The  latest  version  uses 
large  external  caches  (up  to  1Mbyte  Data  and  2  Mbyte  Instruction)  connected  by  a  64  bit 
non-multiplexed  bus. 

The  latest  version,  the  PA-7 100,  has  a  FPU  integrated  on  the  CPU,  along  with  32 
32-bit  general  registers  and  28  64-bit  floating-point  registers.  The  CPU  can  issue  a 
floating  point  instruction  on  the  same  clock  cycle  as  a  CPU  instruction.  External  cache 
controllers  are  on  chip,  along  with  a  separate  System-interface  32-bit  multiplexed  bus 
interface.  It  also  has  a  six  stage  pipeline  for  a  faster  memory  interface.  The  PA-7100 
uses  850, (XX)  total  transistors. 

On  Alpha  there  are  no  special  registers  that  would  prevent  pipelining  multiple 
instances  of  the  same  operations  (no  MQ  register  and  no  condition  codes).  The 
instructions  interact  with  each  otlier  only  by  one  instmetion  writing  a  register  or  memory, 
and  another  one  reading  from  the  same  place.  This  feature  makes  it  particularly  easy  to 
build  implementations  that  issue  multiple  instructions  every  CPU  cycle.  There  are  no 
implementation- specific  pipeline  timing  hazards,  no  load-delay  slots,  and  no  branch- 
delay  slots,  and  no  binary  compatibility  issues  across  multiple  implementations. 

Alpha  is  unconventional  in  the  approach  to  byte  manipulation.  Single-byte  stores 
found  in  conventional  RISC  architectures  force  cache  and  memory  implementations  to 
include  byte  shift-and-mask  logic,  and  sequcnc  ar  logic  to  perform  read-modify- write  on 
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memory  words.  Instead,  Alpha  does  byte  shifting  and  masking  with  normal  64-bit 
register-to-registcr  instructions,  crafted  to  keep  the  sequences  short. 

Alpha  is  also  unconventional  in  the  approach  to  multiprocessor  shared  memory. 
As  viewed  from  a  second  processor  (including  an  I/O  device),  a  sequence  of  reads  and 
writes  issued  by  one  processor  may  1m  arbitranly  reordered  by  an  implementation.  This 
allows  implementations  to  use  multi-bank  caches,  bypassed  write  buffers,  write  merging, 
pipelined  writes  with  retry  oh  error,  etc.  If  strict  ordering  between  two  accesses  must  1m 
maintained,  memory  barrier  instructions  can  be  explicitly  inserted  in  the  program. 

Finally,  Alpha  includes  a  privileged  microcode  library  (PALcall)  which  allows  it 
to  run  full  VMS  using  one  version,  OSF/1  using  a  second  version  (mirrors  many  MIPS 
operating-system  features),  and  NT  with  a  third  version.  Other  versions  can  be  tailored 
for  other  operating  systems.  This  feature  makes  Alpha  an  especially  attractive 
architecture  for  multiple  operating  systems. 


7r4.4.2 _ Aladdin 

The  Aladdin  computer  program  is  sponsored  by  ARPA  and  the  U.S.  Army  Night 
Vision  and  Electronic  Sensors  Directorate  (NVESD).  The  objective  of  the  Alad&n 
program  is  to  develop  a  very  high  performance  miniature  processor.  Texas  Instruments 
and  Alliant  Techsystems  ate  developing  processors  for  this  program.  Additionally,  Texas 
Instruments  is  adiapting  its  Aladdin  processor  for  the  Air  Force  Ultra  Reliable  Digital 
Avionics  (URDA)  program.  The  objective  of  this  program  is  to  develop  a  prototype 
processor  that  combines  a  data  processor,  signal  processor,  memory,  and  system  interface 
on  a  single  SEM-E  card  AT&T  is  also  developing  an  URDA  processor. 

IT's  Aladdin  processor  is  an  Ada  programmable,  modular,  scalable  32-  bit  parallel 
processor,  The  basic  building  block  of  TT's  Aladdin  processor  is  the  Basic  Ff^ssor 
Module  (BPM).  The  BPM  consists  of  a  100  MBPS  R4000  scalar  processor,  a  400 
MFLOPS  Vector  Coprocessor  (VCP),  local  memory  (SRAM),  a  128  Kbyte  secondary 
cache,  and  SPROM  containing  the  configuration  parameters  for  the  R4000  power-up 
sequence.  Access  to  BPM  local  memory  is  via  a  crossbar  switch  and  is  controlled  by  2 
Processor  Interface  Control  (PIC)  devices.  When  multiple  BPMs  are  stacked  together 
each  BPM  interfaces  to  a  25  M word/second  Aladdin  System  Bus  (ASB)  for  inter 
processor  communication,  external  system  communication,  and  data  VO.  Each  BPM  also 
interfaces  to  a  25  Mword/second  Input-Output  Bus  (lOBUS)  for  additional  I/O  bandwidth 
capability. 

The  BPM's  VCP  is  a  nucro-programmable,  custom  designed  pipelined  processor 
based  on  Tl's  8846,47  family  of  signal  j^cssors.  The  VCP  contains  two  32-bit  floating 
point/integer  multipliers  and  two  32-bit  floating  pointTinteger  ALUs.  This  provides  a 
peak  processing  throughput  of  4(X)  MFLOPS  at  a  clock  firequency  of  100  MHz.  The  VCP 
far  exceeds  the  capability  of  existing  processors  in  executing  typical  signal  processing 
algorithms.  For  example,  a  vector  multiply  aitd  add  takes  the  Intel  i86D  0.12  ms,  the 
Ti^320C40  0.05  ms,  and  the  VCP  0.01  nos. 

TT's  Aladdih  configuration  for  the  ARPA/NVESD  program  is  a  stack  of  5  BPMs 
with  a  peak  throughput  of  500  MIPS  scalar  concurrent  with  2(^  MFLOPS  vector 
processing.  This  is  accomplished  in  a  "soup  can"  configuration  in  a  volume  of  4.5  inches 
diameter  by  2.6  inches  long. 
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TI  is  also  adapting  its  Aladdin  processor  for  the  Wright  Laboratorics/NVESD 
URDA  program.  TI's  Al^din  configuration  for  the  URDA  program  consists  of  2  BPMs 
repackaged  in  MCM  packages  to  fit  on  one  side  of  a  SEM-E  card,  lliis  provides  a 
capability  of  200  MIPS/800  MFLOPS  on  the  single  card.  TI  has  included  PiBus  and 
TMBms  mtsrfaces  on  the  other  side  of  the  SEM-E  card.  Liquid-Flow-Through  (LET) 
cooling  is  used. 

'n‘s  Aladdin  processor  is  in  the  assembly  stage  and  its  URDA  processor  is 
entering  preliminary  design  review.  While  TI  is  not  currently  working  on  adapting  its 
Aladdin  processor  for  commercisd  use,  it  has  plans  to  submit  an  unsolicited  Dual  Use 
proposal  for  such  an  effort. 

Alliant  Techsystems  and  AT&T  are  also  involved  in  developing  Aladdin/URDA 
processors.  Alliant's  Aladdin  computer  consists  of  a  distributed  memory  C3(P  based 
MIMD  architecture  combined  with  an  array  coprocessor  with  a  SIMD  architecture 
communicating  over  a  data  flow  network.  Alliant's  Aladdin  processor  is  designed  for  use 
in  image  processing  and  target  recognition  applications  and  is  currently  in  prototype  for 
use  in  an  acoustic  sensor  application.  AT&Ts  URDA  processor  uses  a  C-40^  based 
approach. 


7-4.4.3  Intel's  Evolutionary  Processor  Growth 

Intel  Supercomputer  Systems  Division  (SSD).  unth  support  from  DARFA,  has 
pursued  a  signiEcant  research  effort  in  the  area  of  massively  parallel  processor  (h^P) 
technology  and  system  products  over  the  last  several  years.  The  Intcl/DARPA  R&D 
initiatives  has  have  evolved  from  early  MPP  developments,  the  Touchstone  program,  to 
the  current  TeraFLOPS  initiative.  Intel  SSD  products,  such  as  iPSC/1,  iPSC2,  iPSC/860 
and  the  ?aragon'^  XP/s,  have  evolved  from  these  Intel/DARPA  inidatives. 

All  of  the  iPSC  machines  have  been  multiple  instruction  multiple  data  (MDvp) 
design.*.  The  iPSC/2  and  iPSC/860  have  been  marketed  as  relatively  inexpensive 
supercomputers  and  attracted  wide  interest.  It  was  reported  by  the  IEEE  Spectrum  in 
September  1992  that  over  325  machines  have  been  sold  by  Intel  worldwide.  The 
iPS  C/860  has  been  difficult  to  program  for  peak  performance  both  at  the  node  and 
parallel  levels,  therefore  there  are  very  few  third  party  applications  available  as  yet.  It 
should  be  noted  that  programming  Intel's  machines  is  no  more  difficult  than 
programming  any  other  parallel  time-to-solution  machines.  Intel  continues  its  efforts  to 
improve  the  iPSC/860  user's  environment.  It  actively  works  on  advancing  the  quality  of 
its  software  development  tools  to  facilitate  the  application.  It  can  be  expected  that  future 
developments  along  these  lines  'will  greatly  improve  the  ease  with  which  such  machines 
can  be  programmed. 

The  Paragon^  is  a  MIMD  machine  that  supports  both  the  message  passing  and 
data-parallel  programming  models,  and  is  considei^  one  of  the  world's  most  powerful 
computers.  Two  machines  have  b^n  produced  in  1992,  one  for  Oak  Ridge  National 
Laboratm  and  one  for  the  Boeing  Company.  The  Oak  Ridge  machine  is  a  512  node 
Paragon  ,  projected  to  deliver  over  100  gigaflops  peak  performance.  The  Boeing 


^  C30  refers  to  the  Texas  Instruments  TMS320C30  signal  processing  chip 
3  C40  refers  to  the  Texas  Instruments  TMS320C40  signal  processing  chip 
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Paragon  machine  will  replace  another  earlier  version  MPP  machine.  The  current 
Paragon"  design  supports  66  to  1,000  nodes.  Each  node  will  have  either  two  or  five  Intel 
i860  XP  microprocessors  and  16  to  64  megabytes  of  memory.  In  every  node,  one  of  the 
imcroprocessors  controls  the  message  passing  communications  to  other  nodes,  and  the 
others  are  the  computational  elements.  Each  node  also  has  a  mesh  router  chip  to  enable 
communications  to  any  of  the  four  nearest  neighbors.  Intel  has  received  more  than  thirty 
orders  for  Paragon^  machines,  including  six  for  Europe  and  Japan.  It  is  Intel's  opinion 
that  teraflop  performance  Paragon^  XP/S  systems  can  be  built  today,  but  it  may  not  be 
affordable.  Plans  are  to  wait  for  a  new  generation  of  microprocessors,  memories,  and 
other  VLSI  components  to  make  it  more  affordable.  Intel's  DARPA-sponsored 
TeraFLOPS  initiative  will  evolve  this  R&D  architecture  over  the  next  five  years  and 
provide  the  technology  for  an  affordable  teraflop  30  to  40  million  dollar  supercomputer. 
Also,  the  major  high  pi^ormance  computer  issues  such  as  languages,  programming  tools, 
processor  communications  and  operating  systems  are  being  addressed  by  Intel  to 
facilitate  the  application. 

The  Touchstone  prognmi  has  provided  the  research  and  development  to  advance 
the  Scalable  Parallel  Computing  Technology  base  for  the  1990s.  It  has  served  as  the 
catalyst  for  computing  systems  scalable  over  a  wide  performance  range.  The  recently 
Btinounced  Tera^OPS  initiative  between  Intel  and  DARPA  will  be  the  next  catalyst  to 
advance  the  state-of-the-art  of  future  massively  parallel  high  performance  computers. 
DARPA  has  agreed  to  provide  $21M  over  the  next  five  years  in  a  joindy  funded  research 
agreement  with  Intel  to  accelerate  the  development  of  TeraFLOPS  supercomputers. 
TeraFLOPS  systents  are  going  to  be  developt^  to  meet  what  are  termed  the  "Grand 
Challenge  Problems"  of  science,  as  well  as  important  defense  and  national  security 
applications.  Three  critical  technologies  will  be  addressed  by  the.TeraFLOPS  initiative: 

1.  Advanced  parallel  software  architectural  design,  developed  by  the  Touchstone 
program,  will  be  the  foundation  for  future  generations  of  scalable,  parallel 
supercomputers. 

2.  Advanced  inter  processor  communication  and  computing  concepts  proven  in 
the  Intel  iWARP  real-time  Supercomputer  will  be  enhanced  and  implemented 
in  new  submicron  VLSI  components. 

3.  Development  of  a  new  generation  of  floating  point  RISC  microprocessors 
derived  from  the  Intel  i860  to  increase  computational  power  and  maintain 
software  compatibility  with  the  Paragon. 

This  Intel  and  DARPA  coordinated  effort  is  expected  strengthen  competitive 
position  for  the  U.S.  computer  technology. 


7-4.4.4  Aloha 

The  Alpha  processor  is  a  true  64-bit  RISC  architecture  (it  has  no  32/64  mode  bit), 
with  a  minimal  number  of  32-bit  instructions.  It  is  not  a  32-bit  architecture  that  was  later 
expanded  to  64  bits,  but  rather  it  was  designed  for  64-bit  service  in  the  first  place.  It  was 
designed  with  particular  emphasis  on  multiple  instraction  issue,  multiple  pre^essors,  and 
software  migration  from  VAX  VMS  and  MIPS  ULTRDC.  Alpha  is  a  load/store  RISC 
architecture  with  all  operations  done  between  registers,  based  on  32-bit  instruction  words, 
it  has  32  integer  64  bits  registers  and  32  floating  64-bit  registers.  Longword  (32-bit)  and 
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quadword  (64-bit)  integers  are  supported.  Four  floating  data  types  are  supponed:  VAX  F- 
float,  VAX  G-float,  IEEE  single(32-bit),  and  IEEE  double  (64-bit). 

The  integer  operate  instructions  manipulate  full  64-bit  values,  and  include  the 
usual  assortment  of  arithmetic,  compare,  logical,  and  shift  instructions.  There  are  just 
three  32-bit  integer  operations:  add,  subtract,  and  multiply.  These  differ  from  their  64-bit 
counterparts  only  in  overflow  detection  and  in  producing  32-bit  canonical  results.  There 
is  no  integer  divide  instruction. 

The  floating  point  operate  instructions  include  four  complete  sets  of  VAX  and 
IEEE  arithmetic,  plus  conversions  between  float  and  integer,  but  there  is  no  floating  point 
square  root  instruction. 

The  Privileged  Architecture  Libr^  call  (PALcall)  instructions  deal  with 
interrupts  and  exceptions,  task  switching,  virtual  memory,  and  other  complex  operations 
that  must  be  done  automatically.  PALc^l  instruetions  vector  taa  privileged  library  of 
software  subroutines  (using  the  same  Alpha  instruction  set)  that  implement  an  operating- 
system-specifle  set  of  these  complex  op^ations. 

The  first  chip  implementation  runs  at  up  to  200  MHz.  At  3.3  volts  and  a  ISOMHz 
clock  speed,  the  chip  dissipates  23  watts  of  power,  so  it  will  use  32  watts  of  power  at  full 
speed.  DEC  claims  that  the  speed  of  Alpha  implementations  will  scale  up  from  this  level 
by  at  least  a  factor  of  1000  over  the  next  25  years 


7-4.4.5 _ Touchstone  (DARPAl 

Over  the  last  three  or  four  years  there  has  been  a  technology  explosion  in  all  areas 
of  processor  technology,  emanating  primarily  from  the  commercial  sector  world-wide. 
Intel's  DARPA-sponsored  Touchstone  pro^m  is  a  high  performance  computing  (HPC) 
technolo^  demonstration  initiative  that  takes  advantage  of  such  technologies.  This  R&D 
cooperative  initiative  was  intended  to  demonstrate  the  massively  parallel  processor 
(MPP)  technology  as  the  high  performance  computer  (HPC)  architecnire,  promising  a 
large  price  and  pi^ormance  advantage  over  traditional  supercomputers.  The  Touchstone 
is  a  distributed-memory  multiple  computer,  multiple  instruction,  multiple  data  (MMD) 
model  using  a  2-D  mesh  interconnection  architecture  which  is  very  representative  of 
future  parallel  processing  trends.  Each  processing  node  is  based  on  the  use  of  multiple 
i860™  XP  RISC  microprocessors  for  high  throughput  computation  and  inter  processor 
communication.  The  Touchstone  pro^:am  includes  several  technology  milestones,  such 
as  DELTA  and  SIGMA,  that  resulted  in  the  completion  of  the  experimental  Touchstone 
Delta  machine  and  Intel's  Paragon™  XP/S  product  line. 

The  Touchstone  Delta  machine  was  installed  at  Clalifomia  Institute  of  Technology 
in  Pasadena  in  May  1991,  as  one  of  the  world's  most  powerful  computers  consisting  of 
528  processors  based  on  the  i860  RISC  microprocessor.  The  Touchstone  design  is  a 
scalable  distributed  memo^  MIMD  architecture  arranged  in  a  2-D  mesh  using  message 
passing  for  its  communications.  The  Delta  machine  has  achieved  record  13.9  gigaflops  on 
a  highly^arallel  Linpack  benchmark  for  solution  of  large  system  linear  equations.  The 
Paragon™  XP/S  is  Intel's  current  state-of-the-art  supercomputer  system.  The  system 
delivers  scalable  performance  from  5  to  300  gigaflops  and  is  marketed  as  a  commercial 
product. 

The  Touchstone/Paragon  scalable  design  is  ideal  for  embedded  parallel 
applications  offering  considerable  throughput  and  growth  path  with  continuing 
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Intcl/DARPA  support  for  future  evolutions  under  the  TeraFLOPS  program.  The 
Paragon'^  family  will  result  in  a  considerable  sofrware  investment  that  will  te  supported 
both  by  Intel  and  the  commercial  users. 

Use  of  the  Intel  COTS  software  where  applicable  (e.g.,  compilers,  linkers,  etc.) 
and  the  Verdix  distributed  ADA  is  a  strategy  for  embedded  Touchstone.  Development  of 
domain  specific  application  shells  and  utilities  for  the  Touchstone  are  also  being 
addressed  in  order  to  lower  end  user  costs.  These  include  parallel  expert  systems,  real 
time  object  oriented  data  bases,  and  data  fusion  and  tracking  shells  which  can 
significantly  benefit  advanced  Navy  tactical  aircraft 

Other  DARPA/DoD  software  research  initiatives  in  academia,  industry  and 
government  laboratories  can  be  leveraged  to  suppon  Touchstone  technology  applications. 
The  Paragon™  model  represents  the  industry  leading  microprocessor  and  interconnect 
technology. 

There  are  some  key  developments  in  high  performance  computing,  advanced 
packaging  and  other  related  processor  technologies  that  may  enable  rapid  prototyping  of 
high  poformance  computing  for  milit^  systems  in  a  short  time  at  relatively  low  costs. 
One  of  the  key  developments  is  the  militarization  of  the  Touchstone  system  and  related 
technologies.  Militarization  of  the  Intel/DARPA  Touchstone  for  high  performance 
military  applications  is  already  in  place  with  the  new  Honeywell/DARPA  co-fiinded 
R&D  initiative.  The  program  is  executed  with  a  cooperative  effort  between  Intel  and 
Honeywell  to  repackage  the  Touchstone  design  in  an  advanced  military  package,  using 
the  SEM-E  card  format.  The  new  processor  cards  will  be  developed  by  Honeywell  using 
the  GE  high  density  interconnect  (IlDI)  MCM  technology,  which  arose  from  die  DARPA 
HDI  inidative.  The  SEM-E  high-densiQ'  cooling  design  is  being  provided  by  Lockheed, 
which  developed  the  SEM-E  cooling  system  for  the  F-22  Program.  It  is  Honeywell's 
responsibility  to  produce  and  integrate  this  technology  in  a  military  chassis  as  a  scalable 
system  and  test  it  with  the  exact  same  software  as  the  Intel  commercial  system.  This 
strategy  will  enable  a  military  user  to  select  COTS  HPC  technology  without  repackaging 
if  its  functionality  can  support  the  requirements.  It  also  allows  use  of  the  commerciid 
software  available  from  the  Paragon^  system.  The  DARPA  strategic  requirements  for 
this  effort  is  that: 

1.  No  new  chip  design  for  core  system. 

2.  The  system  must  be  evolved  around  Intel's  commercial  upgrade  cycle  of  two 
years. 

TM 

3.  Execute  the  exact  commercial  system  (Paragon  )  software. 

4.  Follow  military  form  factors. 

5.  Consider  unique  systems  requirements  for  future  systems  such  as  fault 
tolerance,  security,  and  parallel  utilides  for  real-time  applications.  As  pan  of 
this  initiative  Honeywell  is  also  emerging  as  a  le^er  in  the  eml^ded 
software  domain  by  coordinating  the  use  of  the  software  products  being 
developed  by  the  DARPA. 

Under  a  DARPA  contract  GE  developed  High  Density  Interconnect  (HDI) 
multichip  module  technology,  which  is  being  installed  in  a  new  TI  automated 
manufacturing  facility.  The  'll  and  GE  team  can  provide  the  industry's  most  advanced 
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muidchip  mcKiule  (MCM)  foundry  service  supported  by  an  integrated  CAD/C4M  system. 
HDI  is  a  thin  film  muldchip  interconnect  technology  that  connects  complex  1^  chips 
with  copper/polyimide  multilayer  overlay  structure  with  extremely  close  chip-to-chip 
distances  to  achieve  gigahertz  range  speeds.  HDI  offers  high  performance  in  today's 
interconnect  and  packaging  problems  due  to  its  design  using  short  interconnect  distances, 
high-speed,  controlled  impedance,  and  optimum  chip  connections.  It  can  be  fabricated  in 
days  for  rapid  prototyping  since  tlic  technology  is  available  today.  This  is  very  significant 
since  it  offers  state-of-the-art  packaging  technology  that  can  be  used  as  NDL  tiierefore 
saving  the  user  the  non  rccuning  costs. 


7-5  Commercial  Trends  in  Processor  Architecture 

Commercial  architectural  trends  and  efforts  have  evolved  around  open 
architecture  and  massively  parallel  processors  (MPP)  for  high  throughput  applications. 
The  trends  to  new  models  featuring  open  systems  hardware.and  software,  addressing  the 
needs  of  hundreds  of  users,  using  commercial  off-the-shelf  technology  (for  both  hardware 
and  software),  and  enabling  the  application  software  design  to  lead  the  system  design  is 
the  wave  of  the  fumre.  This  section  will  address  only  the  massively  parallel  efforts.  MPP 
systems  represent  a  small  but  rapidly  growing  segment  of  the  ovendl  computer  market. 
Acceptance  has  been  difficult  in  the  past  because  of  the  immaturity  of  system  software, 
but  the  situation  is  rapidly  changing.  MPP  systems  acceptance  is  being  affected  by  the 
lower  order-of-magnitude  price/performance  advantage  over  traditional  computers  and 
the  recent  accelerated  software  initiatives  addressing  parallel  piwessors.  As  an  example, 
Intel  and  Digital  ^uipment  Corporation  have  launched  a  joint  software  initiative  for 
High  Performance  FORTIN  (HPF)  and  other  application-development  and  system 
software  for  massively  parallel  computers.  HPF  is.  an  architecture-independent,  high- 
level  programming  language  that  provides  standards-based  application  portability  wd 
high  permrmance.  The  compiler  to  accept  HPF  is  being  developed  by  the  High 
Performance  FORTRAN  Forum,  made  up  of  cxjierts  from  industry  (Intel,  Digital,  Cray 
Research,  IBM,  and  Thinking  Machines),  academia  and  government. 

Commercial  MPP  computers  are  divided  into  two  market  segments  identified  as 
throughput  systems  and  time-to-solution  systems.  Throughput  systems  run  a  single  job 
on  each  processor,  allowing  many  jobs  to  run  simultaneously  so  that  each  job  runs  as  a 
uniprocessor,  but  many  jobs  complete  at  the  same  time,  Hme-to-Solution  systems  work 
by  dividing  a  single  job  across  multiple  processors,  to  reduce  the  run  time  of  that 
particular  job. 

MPP  computers  are  parallel  computers  with  normally  over  a  hundred  processors 
capable  of  processing  simultaneously  a  single  problem  or  working  in  parallel  on  separate 
problems.  Difficulties  with  the  implementation  of  MPP  systems  is  the  synchronization  of 
the  work  of  the  multitude  of  processors.  This  synchronization  is  achieved  with  complex 
hardware  and  software  design.  The  software  design  is  the  most  difficult  to  complete. 

Another  major  consideration  in  the  past  has  been  the  debates  over  the  merits  of 
single-instruction-multiple-data  (SIMD)  and  multiple-instruction-multiple-data  (MIMD) 
architeemres.  Witii  SIMD,  all  the  processors  execute  the  same  instructions  in  loclutep, 
but  on  different  data.  In  a  MEMD  computer,  however,  each  processor  can  be  executing  a 
different  program  because  it  has  its  own  memory. 

The  market  for  throughput  systems  is  more  mature  and  widespread  at  large 
corporations  throughout  the  world  in  production  environments.  The  key  to  their  success 
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is  the  use  of  commercial  microprocessors  and  support  chip  technology  to  achieve  a  lower 
price  and  performance  advantage. 

Time-to-Solution  systems  are  perhaps  the  most  likely  MPP  computers  to  satisfy 
the  high-performance  architectures  of  future  supercomputers  and  em^dded  military 

applications.  The  Connection  Machine  (CM-5)  and  Intel  Paragon  XP/S  have  emerged 
as  the  leaders  in  the  industry  because  of  their  earlier  availability  and  p^ormance.  The 
CM-S,  which  was  announced  1991  and  delivered  in  1992,  is  the  first  machine  that  is 
capable  of  delivering  ^eds  in  excess  of  one  Teraflop.  Such  configurations  would  sell  for 
more  than  $200  million.  Because  of  this  high  cost,  only  100  Gigaflops  machines  are 
being  produced  presently. 

The  CM-S  machine  is  also  very  flexible  since  it  lets  the  users  program  in 
message-passing  or  data-parallel  modes,  or  combination  of  the  two,  therefore  allowing 

SIMD  operation.  The  Intel  iPCS/860  and  PARAGON  ..  XP/S  have  been  discussed  in 
greater  detail  under  the  DARPA  Touchstone  paragraphs.  Most  of  the  other  time-to- 
solution  systems  address  the  lower-end  of  the  MPP  applications.  As  an  example,  the 
MASPAR  MP- 1100/1200  machines  normally  compete  with  the  low-end  of  the 
connection  machine  applications.  Also  the  n-Cube/2  machine  competes  directly  with  the 
Intel  systems.  It  is  anticipated  the  MPP  high-performance  computer  market  continues  to 
^w  over  the  next  five,  ten,  and  fifteen  years,  and  acmally  double  each  year  over  the 
next  5  years. 


7*5.1  Microprocessor  Chip  Progress 

Microprocessor  chip  advancements  are  perhaps  the  most  explosive  technology 
evolving  world-wide  in  the  commercial  sector  that  can  significandy  increase  performance 
and  functionality  of  military  systems.  The  IEEE  Intemadonid  Solid  State  Circuits 
Conference  held  in  February  1992,  reported  on  a  1000  MIPS  BiCMOS  microprocessor 
with  superscalar  architecture.  An  Intel  Corporation  study,  titled  "Micro  2000  Prediction" 
(1992),  envisions  a  1  inch  x  1  inch  chip  with  50-100  million  transistors  with  four  250 
MHz  processors  offering  750  MIPS/1000  MFLOPS  (peak)  performance.  It  is  anticipated 
that  Intel  will  develop  two  new  generations  of  processor  components  improving  the  i860 
family  by  a  factor  of  ten.  It  is  also  anticipated  that  Intel  will  develop  three  new 
generations  of  interconnect  components  under  the  TeraFLOPS  program  by  mer^g  the 
message  passing  models  of  Touchstone^  and  iWARP™.  These  predictions  suggest  that 
the  TcxbH^OPS  program  goals  of  achieving  scalable  multicomputer  systems  in  excess  of 
one  TeraFLOPS  performance  by  late  1995  is  a  relatively  low  risk.  It  can  be  expected  that 
the  TeraFLOPS  program  will  result  in  three  new  generations  of  HPC  multicomputers  at 
the  300  GFLOPS,  600  GFLOPS,  and  1.8  TFLOPS  performance  levels. 


page  80 


Volume  1 :  Avionics  Technology 


8-0  ADVANCED  PACKAGING  TECHNOLOGIES  AND 
ADVANCED  ELECTRONIC  PACKAGING 


Although  specialized  module  sizes  will  continue  to  exist,  it  is  evident  from  the 
industry  briefs  and  the  PAVE  PACE  reports  that  the  Standard  Electronic  Module,  Fonnat 
E  (SEM-E)  will  be  very  much  in  evidence  in  future  systems.  However,  higher  functional 
densities  will  cause  designs  to  exceed  the  40  watts  which  air  cooled  modules  cannot 
dissipate.  Therefore,  some  type  of  liquid  cooling  will  be  needed  on  future  modules. 
Module  and  system  designers  will  be  challenged  to  prove  that  new  technologies  (such  as 
dripless  connectors)  can  actually  be  supported  in  the  fleet. 

Perhaps  no  trend  will  have  greater  impact  on  module  designs  than  the  muldchip 
hybrid.  These  devices  utilize  Wafer  Scale  Integration  (WSI)  to  combine  into  a  single 
package  the  microcircuits  that  previously  existed  in  separate  packages.  WSI  also  allows 
three  dimensional  arrangement  of  such  silicon  wafers.- The  result  is  much  greater 
functional  density  and  simpler  designs  for  each  SEM-E  module.  In  the  McDonneU- 
Douglas  PAVE  PACE  report,  12  different  devices  were  identified  with  four  different 
package  sizes. 

The  high  functional  densities  will  allow  the  entire  core  processing  architecture  to 
be  housed  in  two  Integrated  Avionics  Racks  (lAR),  versus  the  dozens  of  subsystems  in 
current  generation  aircraft.  Based  on  the  PAVE  PACE  reports,  these  lARs  will  hold 
approximately  twenty  modules  each  witli  five  to  ten  growth  slots.  These  two  units  will 
perform  all  the  data  and  signal  processing  needed  for  communications,  navigation, 
displays,  and  weapons  delivery.  Next  generation  systems  will  also  modularize  the  radio 
frequency  (RF)  elements  (frequency  converters,  receivers,  preprocessors)  into  similar 
integrated  racks. 

The  approach  to  module  packa^ng  for  military  systems  is  quite  different  from 
that  of  commercial  systems.  For  the  military  computer  module,  high  functional  density  is 
needed  to  control  weight,  reduce  computer  size,  and  improve  reliability  by  decreasing 
parts  counts  and  number  of  interconnects.  In  addition,  module  lengths,  widths,  and 
thicknesses  are  determined  by  vibration  modes  and  mechanical  rigidity  requirements. 
These  goals  are  achieved  by  using  multiple  layer  modules  (i.e.,  printed  wiring  boards), 
multi-chip  hybrid  circuits,  and  module  dimensions  such  as  SEM-E.  This  approach  is 
probably  impractical  and  not  cost  effective  for  commercial  boards  which  need  not  meet 
the  harsh  environmental  and  systems  limitations  of  military  computer  modules. 
Conunercial  modules  tend  to  be  much  larger  in  size,  single  layer  (although  sometimes 
double  sided),  and  multiple  chip  hybrids  are  shunned. 

Due  to  the  significant  difference  in  requirements  for  electronic  packaging  for 
military  systems  versus  commercial,  it  is  quite  likely  that  unique  military  packaging 
designs  will  be  needed  for  the  Airborne  Uninhabited  Fighter  (AUF)  applications. 
However,  commercial  modules  are  certainly  viable  for  shipboard,  ground  baskl,  and  rack 
mounted  airbome  equipment  which  does  not  have  such  severe  requirements. 


8-1  Avionics  Environments  and  Packaging 

Packaging  consist  of  three  primary  areas  of  concern  during  design:  connectors, 
thermal  management,  and  structural.  A  fourth  major  area  of  paclraging  which  may  be 
necessary  on  some  projects  is  component  mounting  (mainly  when  circuit  density  forces 
surface  mounting  or  other  advanced  component  mounting  technology). 
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This  section  is  arranged  to  discuss  connectors,  thermal  management,  and 
structural  aspects.  Current  issues  will  be  discussed  in  each  area  as  well  as  technology 
trends  and  cost  considerations.  Repackaging  of  commercial  technology  will  be  discussed 
under  this  general  section  as  well  as  standturdization  issues  related  to  packaging. 

It  must  be  recognized  that  there  are  three  distinctive  environments  in  aircraft 
applications  including  transport,  helicopter,  and  attack/fighter.  Application  of  electronics 
in  these  environments  affects  packaging  in  the  structural  and  thermal  management  areas. 
Transport  aircraft  are  not  very  stringent  in  these  respects.  However,  helicopters  and 
attacl^fightcr  aircraft,  due  to  high  vibration  and  drastic  temperatures,  require  special 
design  emphasis  on  the  structural  and  thermal  management  techniques  for  the  electronic 
equipment.  With  these  environments  in  mind,  application  of  the  typical  commercial 
equipment  on  transport  aircraft  would  generally  be  acceptable,  with  regards  to  packaging, 
but  would  require  special  or  added  ha^ware  to  survive  in  the  helicopter  or  attack/fighter 
environments.  These  extra  structural  and  thermal  management  techniques  are  typi(^  in 
military  equipment  designed  for  these  environments.  When  considering  repackaging 
commercim  equipment  for  helicopters  or  fighter/attack  aircraft,  one  must  have  cost 
incentives  other  than  hardware  development  (such  as  software  reuse  or  tool  availability) 
becatise  repackaging  the  commercial  equipment  can  cost  tirom  75%  to  90%  of  the  cost  of 
newly  developed  h^ware;  making  repackaging  not  necessarily  desirable,  especially  at 
the  circuit  card  level.  Of  course,  repackaging  at  the  semiconductor  die  level  is  very 
inexpensive  compared  to  the  cost  of  special  die  development 

8-2  Standardization  and  Packaging 

Standardization  with  regards  to  packaging  is  effective  and  has  proven  such  in  the 
standard  electronic  module  (SEM)  program,  and  is  documented  to  provide  an  cight-to- 
one  development  cost  savings.  To  standanlize  a  package,  one  must  insure  all  interfaces 
to  the  package  are  defined  and  held  constant  (including  the  connectors,  thermal  interface, 
and  structure  interface).  The  most  effective  point  to  standardize  a  package  is  at  the 
lowest  repairable  or  replaceable  unit.  This  fact  has  significant  raruiftcations  to  the 
logistics  and  supply  systems.  The  SEM  program  was  successful  with  the  philosophies  of 
standardization  at  die  circuit  card  level  and  with  throw  away  cards. 

The  avionics  industry  is  embracing  standardization  at  the  circuit  card  level  with 
the  SEM-E  module.  However,  standardization  of  the  SEM-E  interfaces  has  not  occurred; 
there  is  no  standardization  of  connectors,  thermal  interface,  or  structural  interface.  The 
best  that  specifications  of  the  word  "SEM-E”  buys  is  a  card  that  is  approximately  6"x6". 
Standards  such  as  MIL-STD-1389  for  SEM-E  do  exist,  but  seem  to  be  ignored  in  many 
areas.  Also,  most  SEM-E  cards  are  expensive  and  are  not  designed  as  throw  away  units. 

8-3  Commercial  Avionics  Package  Standards 

The  roost  recent  developments  in  the  commercial  aviunic.s  field  is  being  pushed 
by  Aeronautical  Radio,  Inc.  (ARINC)  for  the  Airborne  Electronic  Engineering 
Committee.  This  effort  includes  Line  Replaceable  Modules  (LRM's)  operating  together  to 
form  an  Integrated  Modular  Avionics  package.  The  size  of  the  LRM  is  determined  fiom 
the  Avionics  Modular  Unit  (AMU).  These  units  vary  in  width  from  1  AMU=l/8  ATR  to 
10  AMU=l/2  Air  Transport  Rack  (ATR);  the  height  is  fixed  at  7.22  inches,  and  the  depth 
at  15.00  inch.  As  an  example,  a  LRM  10  AMU  wide  would  have  the  dimension  of  4.70 
inches  wide  by  7.22  inches  tall  and  IS.QO  inches  long.  The  LRM's  are  to  be  cooled  by 
convection  to  ambient  air.  The  connector  shell  is  capable  of  providing  204  contacts  for  a 
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lAMU  divided  into  thrw  sections.  The  contacts  are  of  the  pin  and  socket  type.  Radial 
has  been  awarded  the  initial  contract  for  these  connectors.  A  four-bar  linkage  mechanism 
at  the  front  of  each  LRM  is  intended  as  an  insertion/extraction  device,  and  is  intended  to 
prevent  relative  movement  greater  than  0.005  inch  between  connector  halves.  The 
substance  of  the  thinking  for  LRM's  is  that  they  should  be  a  self-contained  unit  with  low 
density  components  and  a  low  density  connector  which  plugs  into  an  Integrated  Modular 
Avionics  package  to  provide  some  environmental  isolation  and  is  ambient  air  cool^. 

Contrast  this  ARINC  650  module  with  the  SEM  format-E  which  has  the 
dimensions  of  0.580  inch  wide  by  5.88  inches  deep  by  6.41  inch  tall  with  a  possible  396 
signal  contacts.  The  spine  of  the  module  is  aluminum  instead  of  fiberglass  and  conducts 
the  heat  from  the  module  to  the  surrounding  structure.  The  structural  enclosure  provides 
the  environmental  protection  for  many  modules  mounted  together  for  integration,  but  sdll 
capable  of  individual  replacement  This  very  dense  electronic  package  accomm^tes  the 
time  proven  blade  and  tuning  fork  connector.  The  tuning  fork  contact  mounted  to  a 
prinu^  circuit  backplane  through  a  compliant-section  eliminates  many  troublesome 
solder  joints,  and  can  interface  up  to  twenty-three  layers,  including  power  and  ground 
planes,  and  provide  matching  impedance. 

The  technological  difference  between  these  two  methods  of  packaging  avionics 
may  be  evident  from  the  volume  applied  by  tlte  basic  unit;  509  cubic  inches  for  the 
ARINC  10  AMU  versus  21.86  cubic  inches  for  the  SEM  format-E  (A  difference  of  20 
times).  The  maximum  weight  for  the  ARINC  10  AMU  is  16  pounds  which  is  about  ten 
times  heavier  than  the  SEM  format-E  module.  What  is  propose  as  the  Integrated 
Modular  Avionics  package  for  the  next  generation  transport  could  be  adequate  for  a 
Milita^  Air  Transpm  Service  (MATS)  aircraft,  but  it  would  lose  die  advantage  of  using 
the  avionics  developed  for  other  air  services.  However,  the  discussion  about  weight  must 
also  include  the  necessary  ducting  from  the  Environmental  Control  System  (ECS)  or 
liquid  cooling  system  required  by  the  SEM  format-E  due  to  its  increased  packaging 
density.  Providing  the  cooling  to  the  Integrated  Modular  Avionics  package  allows  the 
package  to  be  located  in  many  areas  of  the  aircraft  where  an  ambient  cooled  package 
could  not  be  located.  In  a  combat  vehicle,  being  able  to  install  the  electronics  in  a 
desirable  location  has  a  great  advantage  because  exterior  profile  must  be  restricted  and  a 
large  amount  of  equipment  carried  internally. 


8-4  Standard  Hardware  Acquisition  and  Reliability  Program 
(SHLARP) 

The  Standard  Hardware  Acquisition  and  Reliability  Program  (SHARP)  is  a  Navy 
standardization  initiative,  using  tri-service  military  standards,  that  addresses  many 
electronics  applications  in  both  shipboard  and  airborne  environments,  including 
flghier/attack  aucraft.  SHARP  is  included  in  the  acquisition  process  through  MIL-STD- 
5400,  as  nondevelopment  items  (NDZ),  and  is  also  mentioned  in  S0(X).2. 

SHARP  comprises  four  separate  standard  product  lines  which  include  the 
Standard  Electronic  Module  (SEM)  initiative,  the  Standard  Enclosure  System  (SES) 
initiative,  the  Standard  Battery  System  (SBS)  initiative,  and  the  Standard  Power  Supply 
(SPS)  initiative. 

The  SHARP  is  supported  by  both  O&MN  and  RDT&E  funding.  The  O&MN  line 
sponsors  the  field  activities  to  maintain  the  current  documentation  and  data  bases ,  as  well 
as  product  periodic  QPL  testing.  The  RDT&E  line  sponsors  the  transition  and 
demonstration  of  new  technologies  in  the  existing  standard  product  initiatives  of  SEM, 
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SPS,  SES,  and  SBS,  Some  of  the  major  technologies  include  fUK?  optics  and  photonics, 
composite  materials,  and  modeling.  The  use  of  the  SHARP  as  the  technology  transition 
approach  makes  it  possible  to  migrate  higher  risk  technologies  into  the  fleet  via  proven 
standaid  product  sp^ificatiqns. 


8-5  Hardware  Interconnects  and  Connectors 

8-5.1  Computer  Backplanes 

A  computer  backplane  is  a  rack  level  interconnect  board  into  which  standard 
modules  are  plugged.  The  physical  transmission  media  for  the  backplane  is  typically  a 
multilayer  dielectric  board  with  deposited  or  screened-on  metal  interconnects.  In  order  to 
increase  the  signal  transmission  speeds  of  the  backplane  interconnect,  controlled 
impedance  metmlization  approaches  are  utilized.  The  interconnect  of  the  backplane 
typically  operates  at  or  near  the  clock  rate  of  the  processor.  The  interconnect  can  be 
point-to-point  in  nature  or  may  be  "bussed"  or  shared  in  a  serial  or  parallel  fashion.  The 
precise  physical  and  operational  interconnect  definition  consisting  of  connector  and  pin 
designation,  the  backplane  media  and  topology,  data  protocols,  transmission  speed  and 
signal  waveforms  is  referred  to  as  a  backplane  bus  standard. 

Most  computer  backplanes  consist  of  a  passive  transmission  media  with  the 
appropriate  connectors.  Massively  parallel  processor  development  programs  are 
currently  exploring  alternative  active  backplanes.  These  active  ^ckplanes  use  active 
switching  devices  to  route  signals  from  a  master  bus  to  provide  a  leconrigurable 
interconnect  system  between  processing  elements. 
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S-S^  Electrical  and  Digital  Connections 

There  are  several  basic  types  of  connectors  used,  including  blade  and  tuning  fork 
bristle  brush,  box  and  post,  tulip  and  hyper  tack.  The  blade  and  fork  connector  is  a  major 
connector  used  in  military  applications  with  the  box  and  post  a  primary  commercial 
interconnect.  Figure  8-5.2  illustrates  these  basic  conventional  connector  types. 


BLADE  dr  fX>RK 


BRUSH 


BOX&POGT 


Figure  8-5.2  Typical  avionics  wiring  connectors. 


The  main  blade  and  tuning  fork  connector  is  a  396-pin  version  which  will  be  used 
for  Military  Future  Bus  and  the  same  pin  style  in  a  larger  version  will  be  used  for 
commercial  Future  Bus,  both  leveraging  the  same  contact  style.  These  pin  styles,  will  be 
specified  by  EIA  and  called  out  by  lE^  1 101.4.  The  brush  style  contact  is  a  relative 
new  contact  technology.  However,  it  seems  in  most  testing  to  date  to  be  equal  to  the 
blade  and  fork.  There  have  been  arguments  for  the  brush  based  on  better  technology,  but 
no  testing  is  conclusive  and  both  the  blade^ork  and  brush  contacts  are  acceptable  for 
fighter/attack  or  helicopter  environments,  lliere  are  differences,  i.e.,  the  blade  and  fork 
has  better  weight  and  density  characteristics  when  the  brush  ^  a  lighter  insertion  force. 
No  engineering  evidence  mandates  the  use  of  the  brush  style  in  lieu  of  the  blade  and  foik 
styles  which  will  be  used  on  military  and  commercial  Futurebus+  circuit  cards. 

It  must  be  noted  that  circuit  card  connectors  can,  and  have  been,  a  major 
contributor  to  system  failures;  most  due  to  some  form  of  corrosion.  Therefore,  it  is 
recommended  that  control  be  placed  on  connectors  procured  for  severe  military 
environments  to  ensure  plating  thickness  and  minimize  susceptibility  to  corrosion. 
Specifically,  connectors  installed  in  attack/fighter  aircraft  or  helicopters  should  be 
procured  to  military  specifications  to  minimize  system  failures  due  to  various  corrosion 
mechanisms.  Commercial  connectors  should  he  acceptable  in  transport  aircraft 
depending;  on  the  criticality  of  the  given  system.  A  final  feature  that  would  be  desired 
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from  a  military  or  commercial  connector  v/ith  high  density  is  a  solderlcss  backplane  Pin. 
This  is  required  due  to  extremely  thick  backplanes  driven  by  system  interconnect  density. 
These  very  thick  backplanes  will  not  allow  adequate  wicking  of  solder  due  to  heating 
problems. 


8*5  J  Technology  Trends 

All  indications  are  that  digital  connectors  will  become  denser,  i.e.,  inquiring  more 
interconnects  per  module.  Two  promising  technologies  that  allow  high  density  are  the 
gold  dot  and  fuzz  button  shown  in  Figure  8-S.3.  Both  will  allow  more  dian  two  times  the 
present  density  in  interconnects.  These  contact  technologies  are  currently  being  used  and 
proven  for  solderless  component  connection  to  circuit  caw.  These  two  technologies  offer 
many  benefits  in  solderless  assembler  and  ultra  high  performance  electrical 
characteristics. 


Figure  8-5.3  -Fuzz  Button  interconnects  between  an  integrated  circuit  and  a 
specialized  printed  wiring  board. 


It  is  expected  that  as  optical  interconnect  technology  progresses,  optical 
technology  will  help  slow  the  interconnect  density  requirements. 


8-5.4  Optical  Interconnects 

Optical  interconnect  technology  is  beginning  to  become  practical  and  cost 
effective  for  some  installations.  The  primary  circuit  card  optical  interconnect 
technologies  are  butt  type  and  iensed  type.  These  optical  termini  are  both  currently 
available.  The  butt  type  is  the  lowest  cost  and  has  lowest  optical  signal  loss.  However, 
Iensed  termini  are  more  tolerant  to  environment  and  mechanical  misalignment  If  losses 
can  be  tolerated,  then  Iensed  tennini  generally  make  the  best  solution  for  backplane  to 
circuit  card  optical  interconnect  The  ¥-22  is  pursuing  a  Iensed  tomini  which  is  V-grove 
ball  type  technology  as  shown  in  Figure  8-5.4. 
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Figure  8*5.4  **  V*grove'  optical  interconnect  used  in  the  F-22. 


This  of  termini  is  not  mature,  however.  Risk  is  nonetheless  regaled  as  low 
and  the  benefits  of  using  multi-fibers  in  small  areas  are  high.  The  F-22  opdcal  termini 
work  should  be  follow^  closely  for  possible  standardization.  It  must  be  noted  that 
standard  termini  can  be  procured  from  MIL-T-2904  and  it  would  be  effective  to  move 
this  ball  lens  termini  into  existing  standards. 

Most  experience  with  fiber  optic  termini  have  resulted  in  high  cost  in 
development  and  production  due  to  ^e  problems  with  fiber  termination.  Fibn: 
termination  seems  to  still  be  an  art  and  not  necessarily  repeatable  widi  automation  of  the 
process  unlikely.  To  make  this  technology  cost  effective,  research  must  be  performed  to 
eliminate  the  te^ous  polishing  termination  process  now  being  done  by  humans.  Anotha 
factor  that  raise  cost  in  fiber  optic  application  are  the  high  cost  of  the  fiber  interfu;e 
circuits,  i.e.,  light  transmitters  and  receiver.  Experience  has  shown  that  these  devices 
can,  and  typically  are,  sensitive  to  the  environment  which  make  application  difficult  in 
avionics.  Effective  application  requires  temperature  compensation  circuits  and  low  noise 
circuit  design  and  fabrication.  These  components  can  cost  up  to  $10K  of  the  cost  of  a 
$12K  electronic  module.  Below  are  several  conclusions  that  can  be  stated  about  current 
fiber  optic  termini. 

A.  Close  tolerances  are  required  for  termini  alignment.  Butt  termini  are  very 
sensitive  to  misalignments  in  any  direction.  Expanded  beam  termini  are 
designed  to  compensate  for  some  axial  separation.  Both  types  of  termini 
usually  require  an  alignment  sl^ve  for  angular  and  side  to  side  alignment 

B.  Connectors  should  provide  environmental  protection  because  the  termini 
won't  work  if  the  int^ace  is  dirty  or  scratched. 
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C.  The  conn^tor  needs  to  provide  and  maintain  a  compFessicn  force  when  using 
butt  tennini.  The  butt  termini  are  usually  designs  to  be  touching.  If  the 
termini  are  separated  by  even  a  small  amount,  the  light  spreads  before  it 
reaches  the  next  tennini,  resulting  in  high  optical  loss. 

Some  logistics  considcradons  to  be  addressed  when  interconnecting  fibers  ate  as 
follows: 

A.  Fiber  type  [single  mode  or  multi-mode  (graded  or  step  index),  bare  fiber  or 
jacketed]. 

B.  Termination  procedure,  installation  procedure,  repair  procedure. 

C.  Strain  relief  method  to  protect  fiber  fir^m  undue  stresses  (e.g.,  exceeding  bend 
radius). 

D.  Splice  method  for  repairing  in-line  breaks. 

E.  Special  tools  for  any  of  the  above  procedures. 

F.  Maintenance  procedures,  required  training  for  technicians. 

G.  flber/cable  routing  on  platform. 


S-SJ  Radio  Frequency  (RF)  Elements 

Radio  frequency  (R^  connectors  have  been  in  use  for  dectides.  Today,  however, 
RF  circuit  functions  are  migrating  to  module  level  packaging  that  is  similar  to  digital 
packaging.  This  trend  is  evident  in  systems  such  as  the  INEWS  and  ICNIA.  The 
avionics  industry  is  moving  towards  system  concepts  that  integrate  RF  type  functions  into 
racks  and  boxes  with  conventional  digital  processors.  This  approach  requires  that  RF 
circuit  cards  (niodules)  have  RF  connectors  that  allow  module  insertion  and  extraction 
into  backplanes.  This  feature  is  called  "blindmatable"  and  places  high  demands  on  the 
performance  of  the  connector.  RF  connectens  are  available  for  integration  into  modules 
that  woik  up  to  18  GHz  with  low  losses.  Little  standardization  has  occurred  in  RF 
connectors.  It  is  obvious  as  integration  of  RF  functions  continues  that  standardizatipn  of 
connectors  must  take  place  to  dlow  multiple  module  application.  little  evidence  is 
available  that  commercial  industiy  is  pursuing  RF  applications  requiring  connectorization 
at  this  level.  Therefore,  it  is  unlikely  that  any  conamcrcial  technology  is  applicable  in 
these  applications. 


8-6  Thermal  Management 

It  must  be  soossed  that  thermal  management  is  more  important  in  military  than  in 
commercial  applications  because  fighter/attack  aircraft  and  helicopters  are  expected  to  be 
immediately  functional  in  both  desert  and  arctic  conditions.  Most  commerci^  equipment 
is  not  required  to  survive  at  these  extreme  temperatures.  Therefore,  thermal  management 
is  not  considered  as  important.  If  a  piece  of  commercial  equipment  has  a  thermal 
problem,  one  can  usually  add  a  fan  or  beater  as  required,  but  in  ^e  gunbay  or  electronics 
bay  of  an  attack/fighter  aircraft,  one  may  not  be  able  to  effectively  cool  electronic  boxes 
due  to  extremely  high  ambient  temperatures. 
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8-6.1  Component  and  Module  Level 

The  reliability  of  semiconductor  devices  decreases  about  two-fold  for  each  ten 
degrees  centigrade  increase  in  temperature  above  a  certain  temperature.  Therefore  it  is 
highly  desirable  to  remove  the  heat  generated  in  the  electronic  devices  very  effectively  to 
an  external  heat  sink.  As  the  speed  and  density  of  circuits  increase,  this  problem  becomes 
more  acute  and  must  be  solved.  The  device/package  interface  is  key  to  this  heat  transfer. 
Exotic  new  materials  such  as  synthetic  diamond  are  being  deposited  on  devices  and 
packaging  materials  to  improve  this  interface.  The  use  of  channels  or  grooves  in  the 
substrate  to  induce  turbulent  flow  of  the  cooling  air  or  fluid  passing  through  these 
channels  is  also  being  pursued.  In  addition  to  the  chip/package  interface,  the  package  to 
module  interface  must  be  optimized  through  novel  materials  or  improv^  heat  removal 
techniques.  Heat  pumps,  liquid  flow  through,  air  flow-through  or  circuit  immersion  are 
concepts  being  exploit.  The  optimum  approach  will  permit  the  highest  circuit  densities 
and  speeds  while  maintaining  or  improving  the  lifetime  and  reliability  of  the  devices. 
Systems  engineers  must  select  the  best  materials  and  techniques  for  the  intended 
application. 


8-6.2  Standard  Computer  Modules 

Standard  module  concepts  with  well  defined  interfaces  have  emerged  as  the 
preferred  packaging  concept  for  computers  and  other  high  density  electronic  functions  in 
both  the  commercial  and  militaiy  sector.  A  module  is  a  large  area  substrate  (e.g.,  4"x6" 
or  6"x9'*)  composed  of  a  thermally  conductive  material  on  which  are  mounted  the 
semiconductor  devices  or  "chips".  The  individual  chips  can  contain  from  hundreds  to 
hundreds-of-thousands  to  millions  of  transistors,  and  are  usually  hermetically  sealed  in 
ceramic  packages  with  metal  leads  or  "bumps".  The  leads  of  the  ceramic  chip  packages 
or  carriers  are  then  soldered  to  an  interconnect  pattern  consisting  of  deposited  metal  and 
insulator  which  has  been  defined  on  the  module  substrate  surface.  Thus  a  very  complex 
electronic  function  can  be  implemented  on  a  standard  module  which  will  have  a  standard 
multi-pin  connector  on  one  edge  of  the  card.  The  sides  of  the  card  are  usually  clamped  to 
a  heat  sink  to  keep  the  circuits  at  the  desired  temperature.  These  modities  are  then 
plugged  into  a  "backplane"  which  sends  signals  in  a  parallel  or  serial  fashion  from 
module  to  module.  The  enclosure  for  these  modules  and  backplane  assemblies  is  refeired 
to  as  an  integrated  rack  and  contains  a  controlled  environment  providing  input  power  and 
cooling  provided  to  the  modular  electronics  inside. 


8-6 Die  and  Component  Level 

Thermal  issues  at  the  die  or  component  involve  mainly  removing  enough  heat 
from  the  die  to  keep  die  or  junction  temperatures  low  enough  to  ensure  that  dermal 
failure  -  which  is  a  major  failure  mechanism  for  semiconductors  -does  not  occur.  One 
of  the  major  reasons  for  the  use  of  ceramics  on  military  components  is  heat  transfer 
which  is  usually  much  better  than  that  of  the  plastic  used  on  commercial  components. 

Trends  seem  to  indicate  the  dies  are  getting  bigger,  denser  and  faster,  which 
means  that  more  power  is  concentrated  in  a  smdl  area.  'Hus  power  relates  directly  to  the 
amount  of  heat  that  must  be  removed.  Die  stacking  will  also  add  to  this  thermal  problem. 

Diamond  films  which  spread  heat  efficiently  over  a  larger  area  are  becoming 
viable,  as  well  as  liquid  immersion  cooling  of  the  die  which  removes  many  of  the  thermal 
resistances  between  the  die  and  the  primary  heat  transfer  medium.  The  use  of  liquid 
cooling,  however,  imposes  maintenance  problems  which  need  to  be  fully  understood 
prior  to  allowing  this  method.  The  best  method  for  die  cooling  is  still  conduction  to  a 
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heat  sink.  This  approach  poses  the  lowest  risk  maintenance  and  logistics  supporu  Liquid 
techniques  at  the  die  level  must  mature  substantially  in  order  to  be  viable.  It  must  be 
noted  that  liquid  cooling  technology  for  die  heat  transfer  has  been  demonstrated  by 
SHARP  and  AAS&T  and  have  achieved  superior  cooling  effectiveness.  However,  the 
problems  mentioned  have  yet  to  be  solved. 


8-6.4  Circuit  Card  and  Module  Level 

Thermal  management  at  the  circuit  card  or  module  level  is  where  most  emphasis 
is  placed,  because  this  level  is  the  easiest  to  effect.  The  major  cooling  or  thermal 
management  techniques  used  at  the  card  level  include  air  impingement,  conduction,  air 
flow  through  thermal  cores,  and  liquid  flow  through  thermal  cores.  Air  impingement  is 
basically  flowing  cooling  air  over  and  between  modules.  This  method  is  used 
substantially  in  both  commercial  and  military  applications.  For  more  severe 
environments,  conduction  cooling  cores  are  effective.  Air  and  liquid  flow  through 
cooling  cores  are  effective  for  use  with  high  power  modules  over  50  watts,  but  are  less 
mature.  Liquid  cooling  assumes  tliat  the  aircraft  environmental  control  system  can 
suppon  it,  which  effectively  limits  it  to  new  platforms  or  major  retrofits.  By  far,  the 
simplest  and  most  cost  effective  method  is  still  conduction  cooling.  The  problem  is  the 
limitation  on  power  level.  We  have  seen  this  power  rise  drastically  on  the  F-22 
electronics  where  liquid  cooling  is  required,  but  we  also  know  of  massively  parallel 
computers  in  military  SEM-E  packages  at  30  wans  per  module  with  Cray  n  power  in  four 
(4)  modules  far  outperforming  F-22  designs.  This  leads  one  to  conclude  that  an 
extremely  high  performance  computer  architecture  can  be  realized  today  without  the 
burdens  of  liquid  cooling  on  the  aucrafu 


8-6  J  Common  Cooling  Methods 

There  are  three  common  cooling  schemes  which  are  presently  used  to  cool 
military  electronic  systems.  These  include  the  followii^:  Direct  air  impingement 
cooling;  Conduction  of  heat  to  an  air  cooled  cardcage;  and  Conduction  of  heat  to  a  liquid 
cooled  card  cage.  Each  of  these  schemes  have  advantages  and  disadvantages  which  must 
be  considered  before  selecting  a  cooling  approach. 

Direct  air  impingement  cools  electronics  by  passing  fan-forced  air  directly  over 
the  electronic  module.  This  method  of  cooling  can  typically  dissipate  20  to  35  watts  on  a 
SEM-E  size  module  and  maintain  the  electronics  at  acceptable  temperatures.  This 
method  should  only  be  used  in  applications  where  the  air  can  be  filtered  sufficiently  to 
remove  contaminants  in  the  air  that  may  cause  the  module  to  fail.  Direct  air  impingement 
is  not  allowed  on  avionics  systems.  Fan  noise  associated  with  this  cooling  scheme  must 
be  considered.  The  increase  fmi  noise  which  is  associated  with  increased  air  flow  does 
not  make  this  scheme  a  good  candidate  for  cooling  high  power  modules. 

Conduction  of  heat  to  an  air  cooled  card  cage  is  a  scheme  that  is  comnoonly  used 
in  existing  military  systems.  This  scheme  is  commonly  used  on  avionics  systems  where 
air  is  available  at  an  acceptable  temperature  to  provide  sufficient  cooling.  Existing 
schemes  using  aluminum  SEM-E  heatsinks  can  effectively  dissipate  approximately  25  to 
35  watts.  The  thermal  properties  of  air  and  the  increased  fan  noise  do  not  make  this 
cooling  scheme  a  good  candidate  for  cooling  higher  powered  modules. 

Conduction  of  heat  to  a  liquid  cooled  card  cage  is  desirable  when  there  is  a  liquid 
coolant  source  available.  This  scheme  is  most  commonly  used  on  shipboard  and 
submarine  systems.  This  scheme  is  recommended  when  noise  is  an  important 
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consideration.  Using  aluminum  SEM-E  heatsinks,  existing  systems  typically  can 
dissipate  up  to  40  watts  per  module  and  maintain  the  components  at  acceptable 
temperatures.  Constructing  the  module  with  materials  which  have  a  higher  therm^ 
conductivity  could  allow  this  scheme  to  dissipate  approximately  80  to  100  watts.  This 
job  could  be  accomplished  using  existing  materials  such  as  composite  heatsinks, 
aluminum  nitride,  and  diamond  film.  The  use  of  these  materials  would  also  increase  the 
module  cost 


8-6.6  Other  Cooling  Schemes 

Other  cooling  schemes,  which  are  not  as  common  as  the  previous  schemes,  but 
offer  increased  cooling  capabilities  are  available.  These  include  the  follo'^g:  Hollow- 
core  air  flow  through;  Hollow-core  liquid  flow  tluough  and  Direct  liquid  immersion  in  a 
dielectric  fluid.  Hollow-core  air  flow  through  provides  cooling  by  passing  air  directly 
through  a  hollow  module.  A  0.125  inch  thick  SEM-E  air  flow  through  inodule  could 
dissipate  approximately  50  watts.  To  dissipate  more  power  would  require  a  thicker 
module. 

Hollow-core  liquid  flow  through  provides  cooling  by  posing  liquid  directly 
through  a  hollow  module.  Liquid  quick  disconnects  allows  the  liquid  to  enter  and  exit  the 
module.  A  SEM-E  size  module  can  dissipate  between  200  and  500  watts.  This  scheme  is 
capable  of  dissipating  heat  for  densely  packaged  modules  which  are  now  resulting  from 
the  use  of  multichip  modules,  chip-on-board  packaging,  and  the  reduction  of  integrated 
circuit  feature  size.  Tlie  placement  of  more  electronics  on  one  module  results  in  smaller 
and  lighter  electronic  systems.  Ibe  use  of  quick  disconnects  allows  the  removal  of 
individual  modules  for  maintenance  purposes.  This  cooling  scheme  may  have  a  greater  _ 
risk  of  leaking  fluid  than  liquid  cardcage  cooling.  There  are  now  several  studies 
investigating  the  reliability  of  the  liquid  flow  through  scheme.  The  thermal  performance 
of  this  scheme  will  be  dependent  strongly  on  the  liquid  used  and  the  module  flow  rate. 
This  cooling  scheme  is  best  suited  for  systems  with  high  power  modules  or  for  systems 
that  may  have  high  power  modules  in  future  upgrades. 

Direct  liquid  immersion  cools  electronics  by  submersing  them  in  a  dielectric  fluid. 
Fluorinert,  a  liquid  manufactured  by  3M  Company,  is  used  in  this  noanner  in  some 
commercial  applications.  This  cooling  scheme  has  not  yet  bMn  applied  to  military 
systems.  This  scheme  is  best  suited  to  chij^on-board  packaging  schemes  where  the 
actual  electronic  chip  v^l  be  in  contact  with  dielectric  liquid.  B^use  the  Fluorinert  has 
relatively  poor  thermal  properties,  boiling  must  result  to  provide  a  thermal  capability 
similar  to  that  obtained  by  liquid  flow  through  schemes. 


8-6.7  New  Cooling  Technologies 

The  two  main  cooling  technologies  under  exploration  fm  modules  include 
composite  cores  and  liquid  immersion  at  die  module  level.  Composite  coo^g  cores  use 
carton  fibers  to  effectively  direct  conducted  heat  off  the  module.  With  this  conduction 
cooling  technology,  and  the  new  massively  parallel  computer  technology  such  as 
nCUBE,  an  argument  can  be  made  that  we  need  not  use  liquid  cooling  for  these 
computing  elements.  (Note:  liquid  cooling  may  be  more  of  a  necessity  in  the  high  power 
RF  area  tl^  in  ^gital  or  signal  processors.) 

AAS&T  is  exploring  liquid  immersion  cooling  at  the  module  which  may  allow 
1,5(X)  watt  modules.  Currently  computation  requirements  can  be  solved  by  propCT 
architecture,  and  not  necessarily  speed  and  increased  power.  It  therefore  seems  that  this 
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ISOO  watt  module  would  most  likely  be  used  in  the  RF  area  (such  as  a  high  power 
transmit-ieceiver  module  using  very  dense  MMIC  technology). 


8*6^  Systems  Level  (Enclosure/Integrated  Rack) 

Thermal  management  at  the  system  or  box  level  usually  involves  flowing  air  or 
liquid  over  or  in  the  box  to  remove  heat.  Air  impingement,  conduction  to  air  heat 
exchangers,  conduction  to  liquid  heat  exchangers,  air  flow  through,  liquid  flow,  and  free 
air  convention.  In  general,  these  methods  support  the  cooling  technique  utilized  at  the 
module  level  Air  impingement  is  typically  not  desirable  due  to  contan^ation  in  military 
environments;  however,  as  mentioned  previously,  it  is  heavily  used  in  commercial 
applications.  Free  air  convection  is  most  desirable  due  to  its  simplicity,  i.e.,  no  fans, 
pumps  or  ECS  connection,  but  it  ^ically  is  limited  to  current  technology.  System  power 
requirements  are  becoming  too  high  in  tnilitary  applications  for  fipee  air  convection  to  be 
effective.  One  of  the  most  common  used  methods  is  conduction  to  air  heat  exchanger.  In 
this  method,  heat  is  conducted  off  the  module  to  a  heat  exchanger  located  in  the  box 
which  is  cooled  by  passing  ECS  air  through  it.  This  method  isolates  the  module  from 
contamination  and  is  efficient.  Conduction  to  liquid  heat  exchanger  cooling  is  identical 
to  air  except  liquid  transfers  heat,  allowing  snoaller  heat  exchangers  and  more  jwwer  in 
the  box  which  equates  to  more  power  in  less  volume.  Again,  restriction  to  new  aircraft  is 
an  issue  due  to  the  liquid  ECS  requirement  Air  flow  through  technology  and  liquid  flow 
through  technology  far  boxes  are  similar  to  their  heat  exchwger  counterparts,  except  die 
heat  exchangers  b^me  manifolds  to  the  modules  where  the  module  core  becomes  the 
heat  exchanger  which  is  more  efficient  Generally,  the  following  order  can  be  used  to 
determine  efficiency: 

1 .  Free  air  convention  (for  lowest  power  disipation) 

2.  Air  impingement 

3.  Conduction  to  heat  exchanger 

4.  Flow  through  air 

5.  Flow  through  liquid  (for  highest  power  disipation) 

Technology  of  semiconductors  seems  to  be  pushing  us  toward  liquid  solutions, 
but  the  push  is  also  driven  by  the  F-22.  Air  cooled  massively  parallel  options  do  exist 
and  could  be  exploited  on  both  new  and  existing  aircraft  With  regards  to  commeicial 
enclosures,  their  utilization  potential  would  be  restricted  to  those  environments  where 
free  air  and  air  impingement  is  acceptable,  which  would  likely  be  transport  aircraft  only  - 
not  attack/fighter  or  helicopter. 


8-7  Structural 

In  general,  structural  problems  are  solved  at  the  circuit  card  and  box  (enclosure) 
level.  Structural-j^blems  usually  arise  from  shock,  vibration  and  thermal  expansion, 
with  shock  and  vibration  being  the  major  contributors  if  surface  mounted  components  m 
not  used.  Shock  and  vibration  environments  are  substantially  different  for  commercial 
and  military  applications,  with  military  being  much  more  stringent  Furtlier  distinction 
can  be  made  in  these  environments  between  transport,  fighter/attack  aircraft  and 
helicopters.  Transport  aircraft  typically  have  low  shock  and  vibration  requirements, 
except  propeller  aircraft  at  the  engine.  In  general,  fighter/attack  aircraft  and  helicopters 
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have  high  vibrfition  levels.  They  also  have  significant  shock  requirements  if  used  for 
carrier  landing.  Commercial  equipment  usually  will  require  some  form  of  protection  to 
survive  (c.g.,  vibration  isolation)  However,  in  the  more  severe  environments  it  is 
unlikely  that  any  added  protection  would  be  sufficient. 

In  general,  military  modules  are  designed  with  a  structural  reinforcing  member, 
usually  an  aluminum  web  or  housing,  where  commercial  equipment  have  no  module 
reinforcement  other  than  the  printed  wiring  board.  Also,  commercial  boxes  and 
enclosures  have  little  structural  integrity  to  survive  in  fighter/attack  aircraft  or  helicopters. 
Enclosures  for  these  are  designed  to  insure  that  vibradon  and  shock  cause  no  damage  and 
they  usually  have  substantially  more  reinforcement  structure  to  obtain  this  goal. 


8-8  Advanced  Power  Systems 

Technology  for  advanced  avionics  systems  is  moving  towards  smaller  device 
geometries,  higher  functional  density,  and  higher  power  densities.  Much  of  the  newer 
devices  will  operate  from  either  3.3  VDC  or  1.5  VDC  power  supplies,  rather  than  the  5.0 
VDC  that  has  been  standard  since  the  mid-1960s.  Higher  power  levels,  coupled  with 
lower  ojperating  voltages,  results  in  higher  current  requirements  and  more  difficult  voltage 
regulation  problems.  Power  conversion  technology  for  advanced  systems  may  be 
substantially  different  from  the  SEM  power  supply  m^ules. 


8-8.1  Power  Supplies  and  Power  Distribution 

Equipment  under  E&MD  presently  are  in  many  instances  using  the  SEM  E 
packaging  scheme.  Power  supplies  are  also  being  packaged  in  SEM  E  modules.  System 
power  requirements  vary  from  hundreds  of  watts  to  sev^  thousands  watts,  and  in  some 
cases  up  to  tens  of  kilowatts.  The  connectors  for  SEM  modules  have  from  250  to  396  pins 
that  are  each  rated  at  around  3  to  5  amperes.  To  conduct  a  high  power  supply  current 
from  the  module  requires  using  many  of  these  pins  connected  in  parallel.  As  the  system 
power  ^uirements  increase  (usually  with  a  corresponding  wei^t  decrease),  more  and 
more  pins  must  be  used.  The  SEM  E  connector  is  one  of  the  limiting  factors  in  increasing 
the  output  current  and  power  for  a  SEM  E  power  supply. 

Assuming  that  the  power  supply  module  is  adequately  cooled,  presently  available 
SEM  E  power  supply  connectors  limit  the  output  current  to  about  100  amperes.  The 
current  is  limited  by  the  number  of  pins  requir^  for  control  signals,  status  signals,  test 
points  brought  out  through  the  connector,  power  dissipation  in  the  connector,  and  the 
current  hantUing  capacity  of  each  pin. 

SEM  E  power  supply  modules  with  higher  output  currents  must  utilize  special 
connections,  lliese  connections  might  be  a  copper  bus  bar  that  is  bolted  to  a  larger 
distribution  bus  (Texas  Instruments  is  using  such  a  technique  in  the  F-22  2.5KW  SEM 
like  power  supply  module  for  the  radar  array).  . 


8-8  Modular  Distributed  Power  Systems  Architecture 

Modular  distributed  power  systems  consist  of  SEM  E  or  SEM-like  power  supply 
modules  distributed  in  an  avionics  enclosure  among  the  "load  modules"  (processors, 
memoiy,  interface  modules,  other).  The  powo*  supply  modules  can  be  paralleled  to  share 
current  to  the  load  modules.  Different  levels  of  r^undancy  can  be  accomplished  with 
such  paralleling.  Figure  8-8.2  shows  a  typical  on  module  power  distribution  system. 
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8*8  J  On«niodule  Distributed  Architecture 

On-module  power  systems  are  conceived  to  consist  of  very  small,  very  high 
density  power  converters  that  will  be  mounted  on  each  load  module  to  provide  the  proper 
voltages  for  that  module.  Some  intermediate  voltage  will  be  distribute  to  each  module 
in  the  avionics  enclosure.  This  voltage  might  be  50  VDC.  This  intermediate  voltage  is 
then  converted  on  each  load  module  to  5.0  VDC,  3.3  VDC,  1.5  VDC  or  other  voltage 
required  by  each  module.  The  aircraft  power  into  the  enclosure  is  filtered  then  converted 
to  the  intermediate  voltage  for  distribution  to  each  module.  Figure  8-8.3  shows  a  typical 
on  module  power  distribution  system. 
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Figure  8-8.3 


8-8.4  On-Module  vs  Modular 

For  low  voltage  systems  (3.3  or  1.5  VDC)  losses  through  the  connector,  through 
the  backplane,  and  again  through  the  load  module  connector  are  critical  The  on-module 
distribute  power  conveners  should  provide  a  well  regulated  voltage  at  the  point  of  use. 
Also  if  the  power  requirements  of  each  load  module  increase  (or  stay,  level)  and  die 
voltage  is  decreased  to  3.3  or  1.5  VDC,  then  the  on  module  converters  should  help  reduce 
the  pin  count  required  to  carry  the  increased  current  levels. 

Existing  SEM  E  power  supplies  range  in  ouqiut  power  density  from  10  watts  per 
cubic  inch  to  25  watts  per  cubic  inch.  Liquid  flow  through  power  supply  modules  are 
expected  to  achieve  i(X)  to  150  watts  per  cubic  inch. 

Adding  an  on-module  power  convener  to  each  module  will  reduce  the  available 
beard  area  for  that  module;  however,  more  slots  will  be  available  since  the  number  of 
power  supply  modules  will  be  reduced.  If  a  200  watt  module  is  to  accommodate  an  on- 
module  convener,  then  the  module  will  be  required  to  dissipate  the  additional  power 
dissipated  by  the  convener.  Existing  SEM  £  power  supply  modules  have  efficiencies 
ranging  from  80  to  85  percent.  If  the  on-module  conveners  achieve  the  same  efficiencies, 
then  the  additional  power  dissipation  will  range  from  35  to  50  watts. 
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8-8J  Technology  Required  for  On-modulc  Power  Converters 

The  technology  developments  required  vo  realize  the  goals  of  the  on-modulc 
power  systems  include:  1)  power  devices  (switch  devices,  rectifier  devices),  2)  inagnctic 
components,  3)  circuit  techniques,  and  4)  advanced  packaging  technologies.  . 

The  power  losses  in  the  power  switch  and  rectifier  devices  becomes  more  critical 
when  the  output  voltage  decreases  to  3.3  or  1.5  VDC.  The  voltage  drop  across  the 
rectifier  circuits  become  a  significant  percentage  of  the  output  voltage.  Lower  drop 
devices  or  rectifier  circuits  need  development. 

Approaches  to  achieving  higher  density  packaging  include  innovative  packaging 
techniques  and  high  frequency  power  conversion  topologies.  Some  power  supply 
developments  are  aimed  at  increasing  the  conversion  l^quency  into  the  megahertz  range. 
These  topologies  include  some  type  of  resonant  circuits  (for  zero  voltage  or  zero  current 
switching).  Thecietically,  as  the  frequency  increases  magnetic  core  materials  decrease  in 
volume  to  the  point  where  the  core  is  no  longer  required.  The  circuits  are  expected  to  be 
packaged  using  RF  packaging  techniques  (strip  line  circuits). 

Rectifier  devices  become  more  critical  when  the  output  voltage  decreases  to  3.3  or 
1.5  VDC.  The  voltage  drop  across  the  rectifier  circuits  become  a  significant  percentage 
of  the  output  voltage.  Lower  drop  devices  or  rectifier  circuits  need  development 


8>9  DC  Power  Supplies 

With  the  rapid  increase  in  gate  packing  density  and  advanced  packaging 
techniques  such  as  multi-chip  modules  (MCM),  electronic  systems  continue  to  shriiik  in 
size.  Power  supplies,  however,  have  not  kept  pace,  even  though  notable  improvements 
have  been  made.  They  are  made  of  magnetic  and  other  passive  components  which  cannot 
benefit  from  the  advances  in  the  semiconductor  technology.  In  today's  advanced  systems, 
power  supplies  are  packaged  witii  conventional  components.  Typical  DC  power  supply 
densities  range  from  1  to  3  watts  per  cubic  inch  (w/cu.  in.)  and  represent  about  20%  of 
the  system  volume.  However,  with  submicron  logic  devices  and  MCM  packaging 
techniques,  size  and  performance  requirements  will  dictate  100  w/cu.  in.  density  and  95% 
efficiency  by  the  late  1990s.  If  these  improvements  are  not  made,  the  size  and  weight 
reductions  promised  by  the  submicron  devices  and  MCM  packaging  will  not  be  realized. 

In  order  to  accomplish  the  dual  goal  of  100  w/cu.  in.  power  density  and  95% 
efficiency,  NRaD,  in  association  with  TI,  has  developed  a  topology  that  substantially 
reduces  switching  losses  by  raising  the  operating  fiequency  (10-25X)  into  the  2  to  5  MHz 
range.  The  additional  specification  of  1.5  V  and  3.3  V  supply  voltages,  (compatible  with 
100  to  300  nm  VLSICs),  was  a  technological  challenge  in  the  development  of  the 
output  rectifiers  to  maintain  the  95%  efficiency.  Traditionally,  a  silicon  Schottky  diode 
with  0.4  V  drop  is  used.  The  NRaD-TI  team  has  developed  a  GaAs  vertical  field  effect 
transistor  (VFET),  reducing  the  rectifier  voltage  drop  to  0.014  V  (from  0.4  V)  and 
provided  rectification  efficiencies  of  99%  (instead  of  80%).  The  potential  of  GaAs 
VFETs  for  microwave  power  amplification  in  the  0.8  to  4.0  GHz  range  is  projected  to 
provide  100  watts  at  1  GHz. 

Program  managers  need  to  support  the  continued  need  for  power  supply  efforts 
such  as  the  Navy/TI  effort  describe  above  or  other  promising  approaches.  It  is  feasible  to 
increase  the  power  supply  densities  to  several  hundred  watts  per  cubic  inch  and 
eventually  to  one  kilowatt  per  cubic  inch. 
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Such  power  supplies  packaged  in  an  MCM  format  will  lend  themselves  to  a  m^ 
distributed  {mwer  supply  and  conditioning  concept  in  advanced  modular  avionics 
architectures.  Such  power  supplies  are  likely  to  be  spread  throughout  an  aircraft  in  the 
future.  Program  managers  ne^  to  be  aware  that  these  advanced  power  supplies  may  not 
be  compatible  with  retrofit  into  older  aircraft  due  to  a  mismatch  in  prime  power 
requirements.  Also,  subsystems  which  incorporate  these  distributed  power  supplies  may 
require  substantial  redesign  to  operate  in  older  aircraft 
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9-0  EFFECTIVE  SOFTWARE  DEVELOPMENT  AND 
MANAGEMENT 


Todays  modem  Naval  aircraft  weapon  systems  incorporate  complex  avionics 
systems  whose  core  functions  are  highly  software-intensive  and  are  very  dependent  on 
the  real-time  processing  of  information  and  data.  One  of  the  lessons  that  has  b^n  learned 
over  the  last  30  years  of  building  Naval  avionics  systems  is  that  when  designing  an 
avionics  system,  a  systems  engineering  approach  must  be  utilized.  The  initial 
architecture  planning  for  an  avionics  system  must  consider  the  requirement'  that  the 
weapon  system  must  meet.  The  systems  engineer  must  determine  the  architectur ;  for  the 
avionics  system  and  decide  what  functions  ^ould  be  implemented  in  hardwtue  and  whai 
functions  should  be  implemented  in  software. 

The  delegation  of  functions/tasks  between  hardware  and  software  is  a  systems 
engineering  activity  which  must  be  based  on  a  knowledge  of  the  capabilities  of  available 
hardwiue  and  software  technology/components  when  the  system  is  designed.  Functions 
which  typically  don't  change  over  the  life  of  a  system  or  arc  time  critical  are  normally 
implemented  in  hardware.  This  hardware  could  be  strictly  analog  or  may  have  deeply 
embedded  software,  i.e.,  flimwarc,  that  is  not  expected  to  change  over  the  system's  Lie. 
Functions  which  will  be  updated  or  changed  mquently  are  usually  implemented  in 
software.  Those  functions/tasks  where  the  software  implementation  would  result  in 
inadequate/marginal  performance  should  be  implement^  in  hardware.  To  achieve 
maximum  flexibility,  as  many  functions/tasks  as  possible  should  be  implemented  in 
software. 

In  today's  systems  the  development  of  the  software  is  often  more  of  a  cost, 
schedule,  and  risk  driver  at  the  program  level  than  is  the  avionics  hardware.  Many 
program  managers,  both  government  and  contractors,  underestimate  the  size  and 
complexity  of  the  software  development  tasks  and  assume  them  to  be  low  risk.  Many  of 
the  DoD  standards  and  accompanying  guidance  for  managing  software  developments  are 
not  specified  as  requirements  in  contracts  or  if  specified,  either  waived  or  ignored  during 
the  performance  of  the  contracts.  In  the  past,  contracts  have  been  put  into  place  with 
incomplete  software  development  requirements;  wliich  limit  the  government's  access  to 
software  cost,  schedule,  and  performance  information;  and  which  restrict  the 
government's  ability  to  require  corrective  actions,  even  when  critical  problems  become 
evident  Shortcuts  have  been  taken  during  the  development  phase  which  resulted  in 
increased  life  cycle  hardware  and  software  maintenance  costs. 

There  have  been  numerous  studies  and  reports  over  the  yean  that  have  addressed 
the  software  problems/issues  involved  in  developing  and  maintaining  software  for  DoD 
systems.  These  studies  were  accomplished  by  highly  knowledgeable  and  credible 
individuals  and  organizations  and  provide  a  basis  from  which  specific  actions  should  be 
taken  at  the  DoD  level.  Annex  E  to  the  draft  1990  DoD  Software  MastCT  Plan  presented  a 
consolidated  perspective  of  the  status  of  related  DoD  activities  at  that  time  and  provides  a 
comprehensive  lict  of  software  issues  which  should  be  addressed.  DoDINST  3000.2  sets 
forth  requirements  in  Part  6,  Section  D,  Computer  Resources,  which  program  managen 
must  ad^ss  during  the  acquisition  process.  These  computer  resources  requirements,  if 
properly  considered/applied  during  the  acquisition  process,  could  result  in  the  majority  of 
the  softwait;  problcm^issucs  which  were  enumerated  in  the  draft  1990  DoD  Software 
Master  Plan  being  addressed  during  the  acquisition  cycle  of  a  weapon  system. 
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9-1  Real-time  Computer  Resources  Development  Dependency  on  the 
Systems  Engineering  Process 

Although  software  is  perceived  by  some  as  distinct  from  hardware*  it  does  not 
stand  alone,  and  must  be  viewed  as  a  part  of  the  weapon  system.  In  order  for  software  to 
perform  its  function,  the  necessary  hardware  and  interfaces  must  be  provided  in  the 
system  design.  The  software  engineering  process  is  part  of  the  overall  systems 
engineering  p^ess  which  is  in  turn  part  of  weapon  systems  acquisition  process. 
There  are  unique  characteristics  associated  with  software  that  preclude  its  being 
developed  and  maiiitaineu  in  a  manner  that  is  satisfactory  for  hardware.  Software  has  no 
process  corresponding  to  the  hardware  manufacturing  process.  For  hardware,  all  of  the 
baselined  equipments  must  be  produced  on  the  manufacturing  floor  per  the  apprjved 
engineering  drawings;  whereas  for  software,  it  is  only  duplicated  and  incorporated  in 
each  of  the  baselined  weapon  systems.  During  the  Post  Deployment  Software  Support 
(PDSS)  phase,  new  functions  can  be  added  to  ^e  weapon  system  through  software  only 
changes  provided  the  system  was  initially  designed  to  accommodate  known/projected 
future  requirements. 

Successful  weapon  system  development  requires  a  systems  engineering, 
requirements  oriented  approach  to  correctly  resolve  and  perform  engineering  tradeoffs 
involving  the  distribution  of  functionality  between  hardware  and  software  for  computer 
resources  which  are  deeply  embedded  within  the  weapon  system.  The  selection  of  a 
hardware  architecture  must  provide  the  necessary  computation  power/memory  and 
required  reserve  capacity.  The  necessary  engineering  processes  and  procedures,  both 
hardware  and  software,  for  accomplishing  the  required  engineering  tasks  from  initial 
design  into  analysis,  implementation,  integration  and  test,  and  through  production  should 
be  in  place  at  the  contractor's  facility  or  must  be  established.  The  haidware/software 
tradeoffs  which  are  made  during  the  development  phase  are  critical  if  life  cycle  hardware 
and  software  maintenance  costs  are  to  be  minimized. 

Specifications  for  computer  resources  should  be  generated  only  after  a  methodical 
systems  engineering  process  has  been  accomplished  including  requirements  traceabilit>' 
from  system  performance  requirements  down  to  detail  design  specifications.  This 
process  includes  aircraft/weapon  unique  critical  performance  requirements  such  as 
environmental,  space,  configuration  and  access  limitation,  electronic  compatibility, 
carrier  suitability,  power,  weight,  and  cooling.  Factors  which  must  be  considered  when 
making  the  hardware/software  determination  in  real-time  avionics  systems  are:  available 
technology,  update  r^uirements  over  the  life  of  the  weapon  system,  ease  with  which  new 
functions  can  be  incorporated,  known/projected  future  requirements,  security, 
redundancy,  degraded  modes  of  operation  due  to  battle  damage  or  hardware  failure,  error 
handling  in  the  event  the  software  performs  out  of  specification,  loss  of  electrical  power 
and  start-up  requirements  when  the  power  is  restored,  timing  constraints,  bandwidth  of 
buses  and  input/output  channels,  and  maintenance  concept 

Many  of  the  problems  found  in  existing  avionics  weapon  system  software  were 
driven  by  the  "systems  engineering"  requirement  to  optimize  hardware  resources  for 
things  like  size,  weight,  and  power.  Memory  has  been  sized  too  small  and  processor 
spe^  has  not  been  adequate  to  perform  all  the  required  functions/tasks  in  an 
unconstrained  manner.  One  of  the  prime  goals  of  systems  engineering  is  to  separate  the 
requirements  from  the  "nice  to  haves"  when  determining  the  haidware/software 
requirements  of  the  weapon  system  being  designed.  In  order  for  the  software  to  be 
properly  designed,  the  necessaiy  hardw^/buse^mterconnects  must  be  provided  for  in 
the  initial  selection  of  the  computer  resources.  Hardware  decisions  should  not  be 
ffnalizcd  until  the  software  design  is  mature  enough  to  minimize  the  risk  of  producing  an 
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avionics  system  which  does  not  or  just  marginally  meets  the  weapon  system 
requirements. 

Many  developers  mistakenly  assume  the  application  of  computerized 
management  tools,  Computer  Aided  Software  Engineering  (CASE)  tools,  and  analysis 
tools  will  provide  or  improve  the  implementation  of  a  more  definitive  system 
development  capability.  If  the  engineering  capability  did  not  exist  at  the  developer's 
facility  in  a  well  established  manutd  form  before  the  application  of  automated  tools,  the 
subsequent  effort  to  create  an  automated  engineering  env^nment  will  be  more  difficult, 
take  longer,  have  fewer  benefits  and  cost  substantially  more.  An  important  capability  that 
must  exist  at  the  system  level  is  the  ability  to  systematically  track  r^uirements  from  one 
level  of  development  to  another,  from  one  stage  of  the  system  life  (^cle  to  another,  and 
between  hardware  and  software  Configuration  Items  (CIs).  Computer-based  tools  to 
support  the  systems  engineering  process  for  today's  complex  systems  are  being  developed 
and  used.  Current  tools  include  the  JIAWGyF-22  Software/System  Engineering 
Environment  (S/SEE)  (Boeing  D&SG)  and  Teamwork '^”'IRqT  (Requirements  Trace), 
and  Teamworl^SA  (Alliant). 


9-2  Computer  Resources  Open  Systems  Architecture 

In-service  avionics  systems  were  built  using  the  latest  technology  that  was 
available  at  the  time  they  were  designed.  Retrofitted  systems  often  were  no  more  than 
extrapolations  of  the  same  architecture  that  was  used  when  the  system  was  first  put  in 
service.  Funding  was  never  available  to  completely  re-design  an  avionics  system  and  re¬ 
equip  a  model/type  of  aircraft  As  a  result  new  computer  hardware  was  added  and 
programmed  to  perform  the  required  functions  within  ^e  limits  of  what  the  computer 
hardware  could  handle  and  funds  could  provide.  The  computer  haMware  often  fell  short 
of  providing  the  long  tenn  growth  computer  resources  reserves  which  were  necess^  to 
perform  PDSS.  The  results  were  that  during  PDSS,  the  software  was  difficult  to  maintain 
and  enhance. 

Even  with  the  new  technologies  that  are  available  today,  the  lack  of  funding  still 
continues  to  heavily  influence  avionics  system  up-grading  and  the  ability  to  migrate  to 
the  open  system  concept  The  architecture  of  new  aircraft  avionics  systems  wUch  are 
being  developed  today  should  be  capable  of  ftuue  growth  and  technology  insertion  based 
cn  an  open  system  design. 


9-2.1  Understanding  Open  Systems 

To  have  an  avionics  system  based  on  the  open  system  concept  an  understanding 
of  what  is  required  is  necessary.  Open  systems  mean  multiple  standaMs.  Just  choosing 
existing  standards  does  not  guarantee  portability  or  interoperability,  nor  does  it  guarantee 
easy  integration  of  multi-vendor  products. 

In  order  to  have  an  avionics  system  which  is  based  on  the  open  system  concept, 
its  design  must  be  based  on  a  set  of  open  system  standards.  This  is  meant  to  ensure 
multi-vendor  hardware/software  interoperability  and  portability.  Unfortunately,  the 
necessary  avionics  standards  are  not  yet  defined  for  all  the  functional  areas  needed  for 
real-time  avionics  systems.  Addition^ly,  existing  standards  frequently  contain  multiple 
options  and  systems  which  were  built  using  those  standards  could  contain 
hardware/software  incompatibilities.  For  example,  depending  on  which  options  of  a 
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Standard  were  selected,  two  avionics  systems  could  result  that  are  compliant  with  the 
same  standard  but  contain  hardware/software  that  can  not  be  interchanged. 

The  requirements  for  the  avionics  system  must  include  the  requirement  that  the 
product  baselined  avionics  system  contain  provisions  for  expansion  or  upgrading  through 
the  incorporation  of  additional  or  higher  performance  hardware/software.  If  this  is  to  be 
feasible,  all  aspects  of  interfaces,  including  physical,  electrical,  functional,  timing, 
protocols,  and  control  must  be  defined.  Any  software  control  functions  required  to 
accomplish  this  must  be  included  in  tlic  initial  design. 


9‘22  Hardware  Architectures 

For  a  discussion  of  system/hardware  architectures,  see  Parts  2,  3,  and  4  of  this 
Volume. 


9-23  Software  Architectures 

Avionics  systems  must  be  designed  to  accommodate  new  mission  needs,  threats, 
and  technology.  An  avionics  system  software  architecture  is  a  key  determinant  of  the 
avionics  system  adaptability.  A  well-conceived  and  well-maintained  architecture  idlows 
for  reusable  components  (both  hardware  and  software)  to  be  smoothly  integrated  in  the 
original  development,  custom  components  to  be  smoothly  integrated  via  standard 
protocols,  and  improved  components  to  be  incorporated  as  replacements  or  enhancements 
arc  needed.  To  be  useful,  the  software  architecture  must  first  be  established  and  include 
provisions  for  change;  second,  it  must  be  controlled  and  maintained  throughout  the 
avionics  system  life  cycle. 

The  software  architecture  which  is  implemented  in  an  avionics  system  is  very 
dependent  on  the  system  architecture  selected  and  the  resulting  hardware  used  to 
implement  it.  If  the  selected  system  architecture/hardware  provides  an  open  system 
architecture  and  the  necessary  computer  hardware  resouices,  a  software  architecture  can 
be  implemented  which  allows  for  future  growth  and  technology  advancement 

Attention  to  software  architecture  begins  with  the  very  first  discussion  of  the 
weapons  system  scope  and  concept,  and  extends  through  the  maintenance  phase  of  the 
avionics  system,  llie  periods  in  an  avionics  system  life  critical  to  establishing  and 
retaining  a  good  architecture  extends  ^m  the  formal  nodncation  to  industry  of 
NAV AIR'S  need  for  the  weapon  system,  through  the  evaluation  of  industry’s  response,  the 
sequence  of  design  reviews  during  the  developer's  design  and  implementation,  and  the 
long  term  maintenance  of  the  avionics  system. 

Some  attributes  of  the  software  architecture  may  overlap  with  concepts  which 
would  be  considered  part  of  the  avionics  system  architecture.  Those  attributes  of  the 
avionics  system  architecture  need  to  be  established  before  the  software  architecture  can 
be  evaluated  and  controlled.  The  specific  content  of  what  is  controlled  under  the 
software  architecture  for  a  specific  aircraft  avionics  system  must  be  established. 
Attributes  should  be  considered  architecture  when  they  express  relationships  that 
contribute  to  the  avionics  system  long-term  tolerance  to  changes;  they  should  be 
considered  design  when  they  are  implemei.tadon  specific. 

General  areas  of  consideration  to  consider  when  establishing  an  avionics  system 
software  architecture  include  the  following: 
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bZiJ _ Software  Control/Partirionine 

The  software  architecture  must  make  provisions  for  several  levels  of 
control/tasks.  These  include; 

•  Operating  System  Task  -  functions  and  services  such  as  provided  in  the 
Portable  Operating  System  Interfaces  (POSIX)  should  be  provided. 

•  System  Manager  Task  •  functions  to  be  performed  for  both  software  and 
hardware  include: 

1)  initialization/start-up 

2)  integrated  diagnostics  both  on-line  and  on-demand 

3)  reconfiguration 

4)  degradation/error  handling/exception  handling 

•  Applications  Software  Tasks  •  iq)ecific  functions  such  as  navigation,  sensor 
management,  communications,  weapon  launch,  displays,  database 
management,  etc. 


9-2.3.2  Flow  of  Data 

The  software  architecture  must  provide  for  the  orderly  flow  of  data  throughout  the 
avionics  system.  Consideration  must  be  given  as  to  how  data  storage  and  retrieval  will  be 
accomplished,  how  data  structures  will  be  modified,  and  what  processes  may  use  the  data. 


9-2.3.3  Timing  and  Throughput 

The  software  architecture  must  provide  the  necessary  structure  to  meet  the  real¬ 
time  requirements  of  the  avionics  system. 


*-2.3.4 _ Intofacine  UycmiK  and  Protocol  Standards 

The  software  architecture  must  provide  for  the  establishment  of  open  system 
protocols  and  interfacing  layers.  Interfaces  which  may  need  to  be  provided  for  include: 
pilot/crew/maintenance  personal,  operating  system,  display/graphics, 
networking/communications,  sensors,  security,  data  base  management,  and  software 
support  environment. 
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9-2.3.5  Software  Security  and  Safety 

The  software  architecture  must  provide  security  to  guard  against  the  compromise 
of  the  weapon  system  from  both  external  and  internal  threats.  As  the  threats  and  the 
complexity  have  increased,  so  has  the  burden  of  the  software  to  ensure  security  with  more 
complex,  multilevel  algorithms.  Systems  safety  requirements  can  be  met  with  a 
combination  of  hardware  and  software.  Software  is  responsible  for  warning  the 
pilot/crew  of  unsafe  conditions,  and  allowing  or  assisting  the  pilot/crew  to  rectify  the 
situation  or  take  alternative  courses  of  action.  Software  may  be  required  to  restrict 
operation  of  certain  physical  subsystems  for  their  own  preservation  as  well  as  that  of  the 
pilot/crew/maintenance  personnel.  The  software  architecture  must  permit  software  to  be 
designed  so  that  it  does  not  create  hazards  through  its  normal  or  abnormal  operation. 


9-2.3.6  Software  Portability 

The  software  architecture  must  provide  for  the  future  incoiporation  of  new 
software,  easily  merged  with  previously  developed  "legacy  software",  whether  it  was 
created  by  eitiier  the  government  or  industry.  This  appears  to  depend  on  the  use  of  both 
good  systems  engineering  and  the  use  of  an  open  system  approach. 


9-2.3.7  Reuse 

The  software  architecture  must  provide  for  the  use  and  development  of  reusable 
software  and  the  use  of  reusable  hardware  components.  The  software  developed  under 
this  architecture  should  be  available  for  use  in  other  avionics  systems  using  an  open 
systems  approach. 


2:2.3.8 _ Vciificaiion  and  yalidatlonTc^i 

The  software  architecture  must  facilitate  the  comprehensive  testing  of  software 
functions  and  those  hardware  items  which  were  designed  to  allow  testing  to  be 
accomplished  by  software. 


_ Tcclinote  Insfiiiipn 

The;  software  architecture  should  facilitate  the  future  insertion  of  both  new 
hardware  and  software.  Software  changes  such  as  new  functions  using  Ada  9X,  new 
operating  system  technology,  new  security  technology  such  as  better 
isolation/partitioning  of  memory  using  software  techniques,  enhanced  performance  of 
new  signtil  and  data  processing  algorithms,  etc.  must  be  provided  for. 


9-2.3. 1Q_  Growth 

The  software  architecture  must  support  both  the  increase  in  the  size  of  existing 
software  components  and  the  addition  of  new  software  components.  It  must  support  and 
facilitate  changes,  additions,  deletions,  and  system  growth  for  the  life  cycle  of  the  weapon 
system,  whether  they  occur  due  to  hardware  and/or  software  mc^ifications.  The 
architecture  must  enable  software  components  to  be  designed  so  that,  in  addition  to  be 
usable  in  the  current  system,  they  are  also  transportable  to  new  higher  speed  hardware. 
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9-2.3. 1 1  Embedded  Training 

The  software  architecture  should  provide  for  the  incorporation  of  funcdons/tasks 
such  that  air  crew  training  can  be  pcrfoimcd  on  the  aircraft. 


9-3  Computer  Software  Development 

Software  provides  system  designers  with  a  flexible  means  to  adjust  system 
elements  and  alter  performance  capabilities.  Such  changes  don't  impinge  negatively  upon 
system  weight,  power,  or  apparent  reliability,  since  no  hardware  changes  are  requii^.  In 
addition,  there  is  no  physical  "wear-out”  mechanism,  so  software  appears  not  to  require 
the  same  logistics  tail  as  hardware.  However,  when  software  changes  are  made  wiuiout 
regard  for  the  effects  on  the  avionics  system,  the  side  effects  caused  by  such  changes  can 
lead  to  severe  problems  at  the  system  level. 

Once  the  avionics  system  and  software  architectures  have  been  determined, 
several  software  design  techniques  exist  which  may  be  utilized  to  implement  the  detail 
implementation  of  the  design.  Both  structured  design  and  object  oriented  design 
techniques  should  be  considered. 


9-3.1  Software  Design  Methodologies 
9-3. 1 . 1  Structured  Design 

Structured  design  techniques  have  been  used  over  the  past  several  decades  for 
developing  software  systems.  Notable  shortcomings  have  prompted  the  emergence, 
almost  at  the  grass-roots  level,  of  alternative  engineering  approaches  that  have 
demonstrably  better  results  in  producing  software-intensive  systems.  While  the  new 
techniques  must  be  examined  for  usefulness,  it  must  be  remembered  that  the  present 
avionics  software  and  systems  engineering  standards  were  built  on  engineering  pruu^les 
strongly  aligned  with  structured  engineering  techniques.  Structured  design  techniques 
should  not  be  dismissed  as  unsuitable  or  unreliable  until  something  which  is  proven  to  be 
better  is  available.  The  present  techniques  have  been  successfully  employed  on 
numerous  avionics  system  programs  and  will  continue  to  serve  a  wide  segr^nt  of  the 
avionics  community.  Thus  it  is  probable  that  a  blend  of  old  and  new  design  techniques 
will  eventually  emerge. 


_ Object  Oriented  Design 

One  new  technique  that  is  emerging  is  the  object  oriented  methodology.  Three 
software  development  phases  must  be  considered  in  the  application  of  the  object-oriented 
technique;  Object-Oriented  Analysis  (OOA)  for  software  requirements  analysis,  Object- 
Oriented  Design  (OOD)  for  software  design,  and  Object-Oriented  Programming  (OOP) 
for  producing  the  software.  The  basic  assumption  of  an  object  orient^  development  is 
that  there  will  be  an  object  oriented  run-time  environment  executing  an  object  oriented 
executable  program.  Ada  is  the  programming  language  mandated  for  use  in  all  DoD 
computer  resources  application;  however.  Ada  is  not  an  object  oriented  language,  but 
rather  an  object  based  language.  As  such  it  supports  some  object  oriented  concepts  but 
not  all.  This  introduces  constraints  in  the  application  of  object  oriented  techniques  for 
DoD  computer  resources  applications.  Industry  and  the  Ada  community  have  developed 
various  strategies  for  dealing  with  the  incompatibilities  of  object-oriented  technolo^cs 
and  Ada. 
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The  basic  strategy  is  to  use  an  OOA  methodology  such  as  Project  Technology's 
Objcct-Chicntcd  Real-Time  Analysis  or  Rumbaugh's  Object  Modeling  Technique,  to 
perform  software  requirements  analysis.  Tliesc  methodologies  arc  supported  by  CASE 
tools  such  as  Cadre's  Teamwork  or  IDE's  Software  Through  Pictures. 

In  moving  from  requirements  analysis  to  design,  two  approaches  are  employed 
when  Ada  is  the  target  language.  One  approach  is  to  continue  the  Object-Oriented 
development  into  design  using  an  OOD  methodology  such  as  Hierarchical  Object 
Orient^  Design  (HOOD),  Project  Technology's  Object  Oriented  Design  Language,  or 
Rumbaugh's  Object  Modeling  Technique  (applies  to  both  analysis  and  design).  Diese 
methodolo^es  are  supponed  by  CASE  tools.  Due  to  Ada  being  the  target  language,  there 
are  limitations  to  the  full  application  of  Object-Oriented  techniques  which  must  be 
factored  as  constraints  during  design.  A  second  approach  is  to  switch  to  an  Ada  oriented 
design  method  such  as  Booch's  or  Ruhr's  Ada  Modeling  techniques.  Finally,  Ada  is  us^ 
to  implement  the  design.  It  should  be  noted  that  Ada  9X  will  provide  suppon  of  object- 
oriented  concepts,  but  the  implications  of  this  capability  to  real-time  software 
development  is  unknown  at  this  time.  Examples  of  conunercial  languages  which  support 
OOP  are  C-h+,  Smalltalk,  and  Eiffel. 

Even  though  there  are  methods  to  realize  object-oriented  solutions  using  Ada,  any 
contractor/govemment  agency  attempting  to  employ  this  t]^  of  development  appro^h 
will  incur  &e  following  risks  especidly  for  complex  real-time  avionics  software.  First, 
object-oriented  solutions  using  Object-Oriented  languages  with  the  associated  run-time 
environment  have  been  shown  to  not  be  particularly  well  suited  to  real-time  applications. 
This  occurs  primarily  because  a  context  switch  is  required  to  operate  on  each  instance  of 
an  object.  >^en  many  objects  are  involved  the  number  of  context  switches  introduces 
overhead  processing  which  can  significantly  affect  proces.sor  loading.  In  addition,  many 
commercial  object  oriented  languages  and  environments  do  not  provide  scheduling, 
prioritization,  and  synchronization  of  software  components  which  are  critical 
requirements  for  real-time  software.  This  issue  is  currently  not  a  large  problem  with 
Ada's  run-time  environment  since  it  is  not  object-oriented,  but  could  brcome  a  problem 
with  Ada  9X  depending  on  its  object-oriented  concept  implementation.  Second,  object 
oriented  lan^ages  and  run-time  environments  are  not  particularly  well  suited  to  error 
propagation^solution  due  to  the  concept  of  inheritance.  Inheritance  basically  allows 
general  data  definition  via  superclasses  with  refinement  through  subclasses  to  object 
instances.  An  object  oriented  environment  works  its  way  through  the  class  structure  to 
execute  specific  object  instances.  An  error  detected  at  lower  levels  cannot  be  propagated 
because  the  higher  levels  have  an  abstracted  knowledge  of  the  data.  Thus  the  higlier 
levels  do  not  have  knowledge  of  lower  level  errors.  Resolution  of  this  issue  is  not  trivid. 
This  is  of  particular  importance  for  avionics  software  where  safety  associated  witli 
software  integrity  is  a  critical  issue.  (Note:  This  is  one  of  Ada's  strong  suits  with  its 
typing  model  and  exception  handling  capabilities.  It  is  unclear  how  Ada  9X  deals  with 
this  issue.)  Third,  DOD-STD-2167A  is  oriented  toward  a  functional  decomposition  of 
software  into  Computer  Software  Components  (CSCs)  and  Computer  Software  Units 
(CSUs)  which  does  not  particularly  mesh  well  with  an  object-oriented  development. 
Issues  here  primarily  deal  with  CSC/CSU  identification  and  associated  integration  test. 

Object-oriented  methods  represents  a  basic  paradigin  shif'  relative  to  functionss 
decomposition  methods  both  in  tenns  of  software  engineering  techniques  and  software 
management.  Generally,  retraining  is  required  for  all  personnel  involv^  with  a  software 
development  including  system  engineering,  software  engineering,  conriguration 
management,  and  software  quality  assurance.  Evidence  clearly  indicates  that  object- 
orient  techniques  for  design,  analysis  and  coding  provide  substantial  improvements  in 
many  aspects  cf  software  engineering.  However,  object  oriented  techniques  have  their 
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own  special  problems  as  discussed  above  and  have  not  been  validated  on  lai;ge  software 
programs  such  as  are  typical  in  avionics  weapons  systems. 


9-3.2  Software  Standards  and  Practices 

Avionics  system  software  is  managed,  designed,  developed,  tested,  and 
documented  per.DOD-STD-2167A  and  DOD-STD-2168  and  their  associated  data  item 
descriptions.  A  Software  Development  Plan  (SDP)  is  required  as  part  of  contract 
proposals.  Navy  field  activities  who  are  peifoiming  PDSS  also  normally  provide  SDPs 
as  part  of  their  Work  Unit  plans.  SDPs  should  contain  planning  for  continuous  software 
engineering  process  improvement  and  computer  resources  risk  management.  For 
avionics  systems  in  the  PDSS  phase  that  were  developed  using  other  than  DoD-STD- 
2167A,  major  software  block  upgrades  to  existing  weapon  systems  software  are  designed, 
developed,  tested,  and  documented  using  DOD-STD-2167A  and  DOD-STD-2168. 

Present  standards  efforts  require  that  certain  approaches  be  followed  when 
designing  and  building  avionics  systems  software.  Present  requirements  mandate  that  a 
specifications-driven  approach  be  used  that  develops  and  manages  documents  as  the 
primary  means  of  controlling  and  managing  the  project  requirements,  design,  and  product 
delivery. 

Certain  military  standards  (including  DOD-STD-2167A,  MIL-STD-499,  DOD- 
STD-2168,  etc.)  which  affect  the  development  of  software  are  currently  being  updated. 
The  planned  updates  will  provide  improvements  in  managing  and  developing  software. 
These  new  standards  differ  from  the  traditional  structured  design  practices  that  permeated 
every  aspect  of  previous  standards  documents  and  actually  inhibited  udlization  of  new 
methods.  ~ 

DOD-STD-2167A,  "Defense  System  Software  Development",  dated  29  February 
1988,  is  the  current  standard  for  developing  avionics  system  software.  It  calls  for  a 
detailed  process  with  specific  deliverables.  NiWAIR  is  responsible  for  tailoring  both  the 
requirements  and  deliverables  for  a  specific  avionics  system  software.  DOD-S1^2167A 
supports  a  tojp  down,  structured  method  (sometimes  called  the  "waterfall"),  however  it 
can  be  used  tor  other  methods  such  as  spiral,  evolutionary  acquisition  (see  DODINST 
5000.2),  etc.  Hie  spiral  development  methodology  is  used  to  overcome  problems  during 
a  developm.  ;t  such  as  incomplete  requirements  at  project  initiatioh.  The  method 
revolves  around  building  enough  to  test  and  compare  against  high  level  requirements. 
With  the  knowledge  gained,  more  detailed  requirements  are  generated  and  the  spiral 
methodology  is  repeats, 

A  new  standard  for  software  development  MIL-STD-SDD,  "Software 
Development  and  Documentation",  is  being  developed  and  will  supersede  DOD-SH>- 
2167A.  It  merges  DOD-STD-2I67A  and  DOD-STD-7935A,  "DoD  Automated 
Information  System  (AIS)  Documentation  Standard",  dated  31  October  1988.  DOD- 
STD-793SA  covers  all  types  of  technical  documentation  for  ^\ISs,  triplications  computer 
programs,  and  revisions  thereto;  as  well  as  the  use  of  existing  or  developed  standards  for 
each  document  t^pe.  MIL-STD-SDD  will  be  a  standard  that  is  applicable  to  the  software 
development  process  throughout  die  system's  life  cycle  and  wul  be  applicable  to  both 
weapon  system  software  and  AIS  developments.  It  defines  standard  terminology,  top- 
level  activities,  tasks,  and  products  for  a  software  development  or  PDSS.  It  provides  for 
transition  from  the  development  phase  to  PDSS.  The  standard  does  not  provide  or 
encourage  any  life  cycle  model  (waterfall,  spiral,  evolutionary,  or  other).  The  standard 
contains  the  building  blocks  needed  to  create  a  life  cycle  model  for  a  software  project 
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The  standard  is  independent  of  any  software  engineering  or  management  method. 
Application  of  the  standard  does  not  depend  upon  any  computer  design/programming 
language.  It  streamlines  the  formal  review/audit  process  so  that  non-waterf^  models  can 
be  employed.  It  requires  that  software  "components"  be  partitioned  out  of  a  system 
design  effort  and,  when  put  under  Configuradon  Management  (CM),  be  called  computer 
software  configuration  items  (CSCIs).  It  requires  the  evaluation  and  inpoiporation  of 
reusable  software  when  it  meets  user  needs,  complies  with  data  rights,  and  is  cost 
effective.  It  requires  software  metrics  at  the  general  level  witliout  spet^ic  realization  of 
those  software  metrics  as  a  requirement.  MIL-STD-SDD  is  in  draft  form  and  final 
approval  is  expected  in  September  1993. 

It  is  imperative  that  NAVAIR  participate  in  the  standards  revision  process  to 
insure  that  NAVAIR's  requirements  are  included.  Effons  arc  on-going  to  improve  the 
standard  engineering  practices  and  make  allowances  for  moving  to  electronic  data  and 
controls  including  data  base  driven  requirements  and  executable  models  for  design  and 
analysis.  This  is  not  just  placing  documents  in- electronic  foim,  but  rather  allowing 
contractual  requirements  to  reside  in  a  configured  data  base  which  is  accessible  by  botii 
the  government  and  the  contractor. 


9-3J  Comniercial*Off*The-Shelf(COTS)/Non-DeveIopinent  Items  (NDI) 

COTS/NDI  is  the  preferred  method  of  satisfying  computer  resources 
requirements.  Reuse  of  previously  developed  and  available  computer  resources  or 
commercial  computer  hardware  and  software  can  reduce  program  costs,  shorten 
acquisition  time,  and  reduce  program  risk.  The  following  order  of  preference  should  be 
us^  when  developing  or  modifying  avionics  system  software: 

-  Use  COTS  software  without  modifications,  although  NAVAIR  will  not  maintain 

COTS  software. 

-  Reuse  existing  Ada  code  maintained  by  NAVAIR,  DoD,  or  other  government 

agencies. 

-  Reuse  and  upgrade  existing  software  maintained  by  NAVAIR,  DoD,  or  other 

government  agencies,  if  it  is  existing  code  written  in  a  high  order  language 

(HOL),  and  the  total  number  of  lines  to  be  modified  and/or  added  is  less  tlm 

1/3  of  total  compileable  source  code  for  the  system. 

-  Develop  new  code  using  Ada. 

-  Request  a  waiver  and  develop  non- Ada  code. 

If  COTS/NDI  software  is  being  procured,  rather  than  being  developed,  the 
programming  language  used  by  the  developer  of  the  COTS/NDI  product  is  not  of  vital 
concern,  unless  it  is  expected  that  the  COTS/NDI  product  will  be  included  as  part  of 
another  application.  If  the  COTS/NDI  software  will  be  used  as  part  of  a  larger  system, 
the  designer  must  ensure  that  the  COTS/NDI  will  be  supported  throughout  tlie  system's 
life  cycle,  and  that  upgrades  to  the  COTS/NDI  will  not  affect  other  parts  of  the  system.  If 
the  system  is  critical,  data  rights  may  need  to  be  acquired.  If  data  rights  cannot  be 
obtained,  this  may  be  justification  for  not  using  COTS/NDI  computer  resources. 
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9-3.4  Languages 

Software  languages  are  an  efficient  way  to  tell  a  computer  how  to  organize  its 
hardware  logic.  The  development  of  software  has  progressed  from  writing  ones  and 
zeros  and  putting  them  into  the  machine  with  front  panel  switches  to  very  sophisticated 
Higher  Order  Languages  (HOLs). 

At  present  the  best  language  for  large  com^ilex  software  systems  is  Ada.  As  a 
follow  on,  Ada  9X  will  provide  additional  efficiencies  and  the  object  oriented  paradigm 
without  increased  dangers.  Ada  is  the  most  portable  HOL  available  due  to  the  existence 
of  tlie  Ada  Compiler  Validation  Capability  (ACVC).  Certification  through  the  ACVC 
results  in  a  higher  degree  of  portability  by  validating  conformance  to  specific  features  of 
the  standard  and  identifying  those  elements  that  are  nonstandard  extensions.  The  Ada 
Joint  Program  Office  (AJPO)  maintains  a  list  of  validated  Ada  compilers;  as  of  January 
1993,  there  were  over  500  validated  Ada  compilers.  This  list  is  av^able  from  the  Ada 
Information  Gearinghousc  (AdalC),  either  from  the  following  address  or  by  downloading 
it  from  the  AdalC  Bulletin  Board  at  (703)614-0215  or  (301)459-3865.  The  list  is  located 
in  the  file  "VAL_COMPiiLP''  in  the  Ada  Infonnatioii  Files  directory. 

Ada  style  guides  are  desirable  for  their  contribution  to  the  quality  and  consistency 
of  Ada  code,  llie  AJPO  has  endorsed  a  Software  Pioductivity  Consortium  (SPC) 
publication  as  a  suggested  Ada  Style  Guide  for  DoD  programs:  SPC-91061-N,  Ada 
Quality  and  Style:  Guidelines  for  l^fessioual  Programmers,  Version  2.0,  1991.  This 
style  guide  should  be  specified  when  procuring  software. 

Other  HOLs  include  ATLAS,  BASIC,  C,  C-H-,  CMS-2,  COBOL,  FORTTIAN,  and 
JOVIAL.  Some  languages,  such  as  LISP  and  PROLOG,  facilitate  the  use  of  computers  to 
mimic  intelligence. 

DoD  has  been  a  user  of  software  languages  throughout,  and  has  contributed 
heavily  to  their  creadon  in  many  cases.  DoD  sponsored  and  paid  for  the  development  of 
the  Ada  language  (called  Ada  83  because  its  American  National  Standards  Institute 
(ANSI)  standard  definition  was  promulgated  in  1983)  in  an  attempt  to  make  large 
programs  testable,  relia'i  !e,  and  poimblc.  DoD  was  very  successful  and  present  estimates 
are  that  for  developments  of  systems  requiring  over  10,000  lines  of  code,  it  is  more 
economical  to  use  Ada  because  of  the  savings  in  debugging  time  alone.  Additional 
savings  result  from  the  increased  reliability  of  the  software  and  from  the  decrease  in  life 
cycle  maintenance  costs. 

In  order  to  promote  an  engineeiing  environment,  it  is  necessary  to  limit  and 
coiviTol  the  language:^  allowed  in  a  system.  The  latest  trend  in  computer  languages  has 
be<:n  towaiUs  "object  oriented"  languages.  These  are  languages  in  which  one  creates 
"objects",  which  are  pieces  of  code  having  a  defmite  functionality.  An  object  contains 
the  definition  of  the  dam  structures  and  what  operations  that  can  be  perfonned  on  the 
data.  This  ^dlows  objects  to  be  placed  in  a  library  and  reused  by  other  programs,  instead 
of  having  to  continudly  reinvent  them.  The  usefulness  is  somewhat  limited  by  the  fact 
that  objects  may  "inherit"  from  other  objects,  so  that  an  object's  true  definition  may  be 
heavily  nested.  That  means  that  to  use  it,  one  has  to  have  the  entire  library.  To 
understand  exactly  how  an  object  performs  its  functions  requires  a  study  of  the  entire 
string  of  antecedent  objects.  For  printer  and  display  routines,  this  is  satisfactory,  but  for 
real-time  avionics  systems  there  is  some  question  as  to  its  usefulness.  In  fact,  the  cunent 
version  of  Ada  fully  supports  two  of  the  four  characteristics  of  an  Object  Oriented 
Programming  (OOP)  language.  That  is,  abstraction  and  encapsulation  are  supported. 
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inheritance  and  polymorphism  are  not.  Inheritance  can  be  simulated  in  Ada  83  with  little 
difficulty,  but  simulating  polymorphism  is  painful  to  the  point  of  being  impossible.  Ada 
9X  will  include  inheritance  and  polymorphism.  Furthermore,  the  proposed  forms  of 
these  new  features  have  also  been  stable  for  some  time.  Although  not  strictly  an  OOP 
concern,  A^  9X  also  supports  the  optional  definition  of  constructor  and  destructor 
routines  for  any  user  defined  type.  Thus,  Ada  9X  will  be  an  object  oriented  language.  Its 
fonns  of  inheritance  and  polymorphism  are  different  from  the  forms  in  any  other  OOP 
language,  but  then  no  two  of  the  other  OOP  languages  use  the  r.ame  fonns  either.  One  of 
the  key  features  of  Ada's  version  of  these  features  is  that  they  arc  being  added  to  the 
language  in  a  type-safe  manner.  Thus,  it  will  still  possible  to  gel  the  extensive 
compile-time  checks  supplemented  by  additional  run-tiroc  checks  that  arc  one  of  Ada's 
prime  characteristics. 

Finally,  it  should  be  noted  that  the  entire  question  of  interfaces  between  software 
and  hardware  is  an  are.a  of  active  research.  As  an  example,  a  class  of  machines  called 
"RISC"  (for  Reduced  Instruction  Set  Computers)  has  arisen  a  the  past  five  years.  They 
are  designed  to  exploit  repetition  normally  found  in  large,  complex  programs.  Non-RISC 
computers  have  hardware  resources  which  arc  only  infrequently  used  (but  promote 
efficiency  when  used)  requiring  complicated  instructions  to  control  those  rosou'ces.  An 
example  might  be  a  floating  point  unit  on  a  machine  doing  only  integer  arithmetic.  The 
way  around  including  this  seldom  used  equipment  was  to  cm^d  special  operations  like  a 
floating  point  multiply  in  the  compiler  software,  and  to  cany  it  out  by  paforming  a  scries 
of  simple  single  cycle  operations.  By  doing  this,  the  more  often  used  instructions  could 
be  carried  out  much  faster  because  the  hardware  cycle  was  made  much  simpler  and 
shorter.  This  in  fact  works  well  in  most  applications.  But,  the  so  called  "RISC" 
machines  have  started  to  add  resources  as  the  hardware  technology  has  grown.  Thus,  it 
will  be  ncccssaiy  for  NAVAIR  to  maintain  an  active  monitoring  of  this  whole  area  of 
computer  research  in  order  to  keep  up  with  the  best  a'^ailable  commercial  equipment  and 
technologies. 

Most  commercial  operating  systems,  including  the  UNIX  operating  system,  are 
written  in  C.  Additionally,  C  is  the  most  commonly  used  language  for  COTS  softwue, 
communication  programs,  and  bindings  to  existing  systems.  In  .systems  where  COTS 
software  is  to  be  used  extensively,  the  amount  of  non-COTS  code  that  has  to  be 
developed  and  the  interfaces  to  the  COTS  software  need  to  be  considered  when 
evaluating  the  long-term  cost/bcncfits  of  using  C  versus  Ada  as  a  development  language. 
In  most  cases,  developing  Ada  links  to  existing  C  bindings  has  proven  to  be  an  effective 
development  method.  Funhermore,  in  appucations  where  concurrent  processing  is 
required,  /  da's  inherent  implementation  of  concurrent  methods  is  preferable  to  C,  since 
concurrent  processing  in  C  is  handled  by  reference  to  UNIX  operating  system  calls. 
Ada's  concurrency  methods  are  independent  of  the  operatinp;  systcin, 

C4-+  contains  object-oriented  extensions  to  C.  The  same  considerations  described 
previously  for  C  also  apply  for  C++.  In  addition,  C++  is  not  as  widely  available  as  Ada. 
FORTRAN,  JOVIAL,  and  LISP  have  been  used  traditionally  for  real-time  and  scientific 
processing.  The  wailabiliiy  of  Ada  compilers  and  cross-corapileis  make  Ada  a  cost- 
effective  alternative.  Although  FORTRAN-90  contains  added  capability  over 
FORTRAN-77,  it  docs  not  contain  any  capabilities  that  make  it  preferable  to  Ada  for 
large  systems. 

COBOL  is  used  extensively  in  data-intensive,  non-embedded  systems  such  as 
business  and  legacy  software.  Ada  83  has  been  shown  to  be  effective  in  these 
applications  as  well  as  less  costly  to  maintain.  Furthermore,  Ada  9X  will  include 
features,  such  as  fixed  point  arithmetic,  that  have  been  identified  as  the  cause  of 
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portability  issues  in  these  applications.  The  re-engineering  of  COBOL  programs  to  Ada 
has  been  proven  to  be  more  cost-effective  than  maintaining  ihe  existing  systems  in  the 
long  term. 


9-3  J  Software  Engineering  Environments/Software  Tools 

The  automation  of  the  software  development  process  using  Software  Engineering 
Environments  (SEEs)  involves  having  an  established,  repeatable,  and  consistent  software 
process.  Procedures  and  methods  that  establish  the  en^neering  approach  along  with  all 
necessary  engineering  events,  controls,  tools,  and  management  functions  must  be 
embraced  by  the  SEE.  SEEs  must  also  exist  within  the  broker  context  of  the  systems 
engineering  process. 

Depending  on  the  particular  avionics  system  being  developed,  a  broad  range  of 
software  tools,  ranging  from  database  management  to  software  design  tools  to  project 
nianagement  tools,  may  be  required  to  support  the  effort.  Software  tools  can  be  grouped 
into  general  types  such  as  management  tools,  development  tools,  and  laboratory  tools. 

Management  tools  include  tools  to  perform  planning,  scheduling,  requirements 
traceability,  configuration  control,  and  documentation.  Development  tools  include 
structured  analyzers,  editors,  compilers,  code  generators,  debuggers,  and  emulators. 
Laboratory  tools  include  automated  testers,  data  manipulators,  simulators,  real-time  non- 
instrusive  testers. 

Many  of  the  tools  required  for  developing  avionics  system  software  exist  today; 
however,  there  is  little  integration  between  and  among  these  tools.  Future  SEEs  must  be 
seamlessly  integrated,  easy  to  use,  suppmt  a  distributed  environment,  support  graphical 
interfaces,  and  have  a  cost  effective  licensing  policy  which  recognizes  the  true  patterns  of 
tool  usage. 


9-3.6  Operating  Systems 

Operating  systems  are  very  general  pieces  of  software  which  provide  certain 
interface  and  commonly  used  services  to  other  applications  software,  thereby  hid^g  tiie 
details  of  the  computer  from  the  applications  software.  Examples  include  VMS  (DEC), 
UNIX  (Bell  Labs),  MS  DOS  (Microsoft),  OS/2  (IBM-PC),  etc.  The  types  of  services 
provided  include  Input/Output  (tape,  disk,  video  tenninal),  memo:^  allocation  for 
applications,  loading  and  running  applications  software,  switching  of  jobs  under  multi- 
talcing  systems,  accounting,  file  storage  and  retrieval  services,  print  formatting,  and 
general  interfaces.  Although  very  useful  for  general  purpose  computers,  they  take  up  too 
much  memory  and  execution  time,  and  sometime  cause  non-determinism  for  real-time 
systems.  For  that  reason,  real-time  systems  tend  to  be  "complete"  and  perform  all  their 
own  services  by  displacing  the  operating  system  once  they  are  loaded. 

Since  the  inteiface  between  operating  systems  and  applications  programs  differs 
for  each  operating  system,  there  are  definite  problems  with  portability'  of  applications 
between  platforms  running  different  operating  systems.  To  alleviate  that  problem,  a  new 
standard  (POSIX)~lias  been  proposed  and  is  being  developed.  Although  it  will  not 
provide  a  standard  operating  system,  it  will  provide  a  set  of  standard  services  and  a 
standard  method  for  applications  programs  to  evoke  those  services,  thus  allowing  the 
applications  to  be  ported  to  any  computer  utilizing  a  POSDC-comnliant  operating  system. 
I^SDC  will  probably  have  to  undergo  several  revisions  before  it  is  mature  enough  to  be  a 
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really  firm  standard,  but  several  software  and  computer  houses  are  already  advertising 
"POSIX  Compliant". 

Because  of  the  increased  complexity  of  the  avionics  systems  and  associated 
computer  resources,  it  is  becoming  more  and  more  difficult  to  start  from  scratch  when 
developing  modem  avionics  systems.  For  real-time  systems,  developers  have  started  to 
utilize  so  called  "real-time  kernels":  operating  systems  which  have  all  the  non-essentials 
stripped  out  and  are  carefully  programmed  to  make  sure  that  all  provided  operations  are 
deterministic  in  nature  (especially  regarding  their  completion  time). 

Although  operatin;^  systems  cause  real-time  problems,  the  move  to  distributed 
computational  systems  will  require  the  use  of  some  cort  of  operating  system  just  to 
maintain  the  message  traffic  between  applications  on  multiple  computers.  Although  this 
will  be  less  efficient  than  a  tightly  coupled  system,  the  add^  time  performance  provided 
by  the  increased  hardware  operating  in  parallel  can  more  than  compensate  for  the 
dec^sed  efficiency.  The  most  touted  parallel  operating  system  at  present  is  "MACH", 
which  is  a  reduced  U1>1X  system  that  runs  cooperatively  on  multiple  heterogeneous 
platforms. 


9-3,7  Testing 

Testing  is  an  important  pan  of  software  development,  is  seldom  adequately  done, 
and  never  completely  done.  That  is  because  all  computers  are  finite  state  machiney  (dtey 
have  a  finite  numb^  of  gates  each  having  only  two  states,  so  the  entire  machine  can 
always  be  represented  by  a  binary  number  whose  length  equals  the  number  of  gates  in  the 
machine),  but  the  progression  from  one  state  to  another  is  not  well  defined.  Assuming 
the  computet  hardware  is  functioning  correctly,  the  software  is  responsible  for  defining 
the  transition  from  one  state  to  another.  Thus,  ^c  flexibility  provided  by  the  software  is 
the  true  enemy  of  adequate  testing. 

For  a  home  computer  to  go  into  an  unknown  state  where  something  totally 
unexpected  happens  may  be  annoying;  but,  for  an  aircraft  flight  control  computer  to 
malfunction  during  a  carrier  landing  creates  hazards  for  both  the  pilot  and  his  shipmates. 
Also,  some  computers  cany  information  which  needs  to  be  kept  secure,  and  operation^ 
systems  need  to  have  their  applications  software  secure  from  either  unwanted  or 
unexpeaed  changes.  Unexpected  sequences  in  a  computer  can  open  the  entire  system  to 
unwanted  intrusion,  and  subsequent  damage  or  destruction  of  the  operation^  software. 
For  these  reasons  it  is  very  important  that  a  military  computer  in  an  avionics  system  does 
only  predictable  things  at  all  times. 

Since  it  is  clearly  impossible  to  exhaustively  test  all  states  of  a  piece  of  computer 
h^waie,  the  only  solution  is  to  test  all  the  pieces  and  connections  between  those  pieces. 
Since  software  and  computer  hardware  have  the  same  basis,  the  same  rational  holds  true 
for  software.  The  only  way  to  test  large  software  programs  is  to  create  small  well  defined 
functional  blocks  and  test  them  completely.  If  Ae  structured  engineering  technique  is 
used,  these  blocks  will  be  created  in  a  top  down  marmer,  so  that  ^e  requirements  for  each 
block  and  the  necessary  connections  and  tests  are  well  Imown. 

Thus,  the  testing  seems  easy,  but  tedious.  In  fact,  the  necessary  tools  to  partition 
software  into  rationally  functional  blocks  does  not  yet  exist  for  the  most  part.  Those 
which  do  exist  will  often  give  very  different  answers  for  slight  differences  in  initial 
inputs.  But  this  partitioning  problem  is  exactly  synonymous  with  the  systems 
engineering  problem  of  breaMng  requirements  at  each  level  into  simpler  sets  of 
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requirements,  and  then  testing  them  for  consistency  and  completeness  l^fcre  preceding 
to  the  next,  lower  level.  On  finally  reaching  the  implementation  level,  the  entire  system 
can  be  validated  by  only  running  selected  individual  strings  at  the  lowest  level  while 
running  most  of  the  system  at  its  highest  level.  This  is  a  variation  of  "correct  by 
construction."  In  order  to  perform  software  testing  adequately  though,  it  is  necessary  that 
testability  be  built  into  the  process  from  the  start,  and  be  given  at  least  equal  status  to 
every  other  part  of  the  system  design  and  build. 


9*3.8  Software  Reusabdity 

Software  reuse  includes  the  reuse  of  software  designs,  systems  architectures, 
software  components,  requirements  and  test  documentation,  tools,  test  data,  interfaces, 
concepts,  and  source  and  object  code.  Realistic  reuse  leverages  the  best  solutions, 
designs,  and  architectures  for  use  in  avionics  sysu  ms.  Contractors  are  now  realizing  that 
reuse  of  these  elements  are  just  as  valuable  if  not  more  so  than  the  actual  source  code. 

The  reuse  of  these  different  products  during  software  development  rather  that 
producing  them  fiom  scratch  can  reduce  the  software  cost  considerably.  In  addition, 
software  which  has  been  frequently  reused  has  undergone  much  better  testing  than  the 
average  project  can  provide.  This  provides  for  a  much  better  life  cycle  maintenance, 
aided  by  the  larger  user  base. 

Using  previously  developed  avicnics  software  makes  economic  sense  just  as  use 
of  previously  developed  avionics  hardware  in  other  mixlel/iype  of  aircraft  makes 
economic  sense.  In  the  past,  there  was  little  standardization  in  "deeply"  embedded 
software  across  aircraft  platforms,  and  due  to  the  differences  in  languages  and  compilers 
used  on  (Ufferent  platforms,  vepr  little  of  the  software  was  reusable.  With  new  avionics 
system  software  teing  written  m  Ada  and  the  drive  toward  open  systems,  opportunities 
for  economical  software  reuse  will  exist. 

In  the  past,  software  reuse  has  been  lim'<ed  to  modernization  within  a  single 
aircraft  model/type.  The  requirements  and  design  from  an  earlier  aircraft  uiodeUtype 
were  used  as  a  baseline,  and  changes  and  ^Iditions  made,  rather  that  starting  a  whole  new 
development  for  each  upgrade.  Reuse  of  software  in  new  aircPift  programs  from  other 
existing  aircraft  models/t)^  was  not  feasible. 

There  were  a  variety  of  reasojus  vvhy  software  reuse  was  not  practiced  on  a  large 
scale  in  NAY  AIR  as  well  as  other  DoD  systems.  The  two  greatest  were  cost  and 
ownership  and  these  two  problems  still  retnain.  In  order  to  take  advantage  of  what  has 
already  been  created,  a  detailed  analysis  (called  domain  analysis)  is  required  to  review 
what  other  similar  systems  have  built,  and  how  they  match  the  requirements  of  the  new 
system.  Most  aircraft  programs  have  limited  time  and  budges,  and  cannot  afford  this 
extra  step.  And,  the  previous  software  did  not  receive  the  extra  amount  of  effort  and 
dollars  to  assure  that  it  would  be  designed  and  documented  so  that  it  could  be  reused  by 
another  aircraft  weapon  system. 

Perhaps  the  biggest  single  impediment  to  software  reuse  are  the  legal  issi><iis 
surrounding  ownership.  If  developers  find  proprietary  software  that  fills  a  requiremc-nt, 
they  must  negotiate  with  the  builder.  If  the  buyer  then  adds  functionality  to  the  software, 
he  can  resell  it  in  some  cases  (derivative  rights)  with  royalties  back  to  the  originator.  The 
issue  of  warranty  if  a  system  problem  occurs  further  confuses  the  situation.  Thus  most 
developers  have  found  it  to  be  easier  to  build  from  scratch  than  to  deal  with  these  issues. 
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Because  of  this  and  for  reasons  of  life  cycle  support,  DoD  has  in  many  systems 
chosen  to  own  all  rights  to  the  system  built  by  a  given  contractor.  This  affords  DoD  the 
ability  to  use  another  contractor  or  Navy  field  activity  tc  support  the  system  in  the 
maintenance  phase.  But  the  initial  contractor  is  not  allowed  exclusive  rights  to  resell  any 
pait  of  the  system,  so  it  is  not  built  to  be  reused.  Nor  is  there  much  effon  on  the  part  of 
contractors  to  build  new  systems  or  subsystems  o''  their  own  money,  since  they  face  the 
prospect  of  having  the  government  force  them  to  relinquish  owncrsldp.  But  even  if  the 
DoD  relaxes  its  ownership  requirements,  there  arc  not  many  military  systems  for  a 
prospective  industry  player  to  use  to  amortize  costs.  This  argues  strongly  for  close  ties  to 
conunercial  endeavors  which  need  similar  components. 

Given  that  software  reuse  is  a  viable  means  for  reducing  risk  and  cost,  there  is  no 
support  environment  to  facilitate  software  builders  in  developing  software  that  is  reusable 
later,  cr  finding  and  integrating  existing  software  for  their  current  application.  The  DoD 
Sofovarc  Reuse  Initiative  is  corrdinating  a  variety  of  efforts  to  build  this  in^structure. 
Among  these  are  the  creation  of  libraries  and  support  tools  (cla.ssification,  browsers). 
Computer  storage  of  software  is  relatively  easy,  but  >«tricving  software  elements  has 
prov  ed  to  be  much  harder.  Classlixation  schemes  arc  in  development  to  tag  softwtue. 
Just  an  library  browsers  are  available  to  aid  in  quickly  scanning  libraries  for  books  and 
articles,  so  are  software  browsers  being  developed  to  aid  developers  in  retrieving 
appMcable  software.  As  vtith  any  retrievable  items,  catalogs  of  software  elements  are 
T^uired,  id  must  be  amiputer  based  because  of  the  lar^o  number  of  elements.  Since 
most  companlei;  have  ih  own  proprietary  libraries,  and  s^ice  DoD  is  sponsoring  several 
library  efforts,  there  is  a  need  for  interpretability  among  libraries.  Indeed,  DoD  is  also 
sponsoring  a  joint  effort  to  provide  for  int'fi.tpretability  of  )itM«ries. 

The  lov/er  cost  and  risk  of  a  previously  developed  software  (cither  or  COTS) 
application  ptjts  great  pressure  on  the  Navy  program  managers  to  con3ider  its  use.  It 
should  be  r.:fted  however,  this  lower  cost  comcn  with  important  problems  to  be  solvid. 
First  and  foremost,  the  limited  rights  that  come  with  CX)TS/NDI  may  preclude  visibility 
into  the  software  to  allow  safety  analysis  required  for  airtxime  systems,  and  precludes 
detailed  analysis  to  ensure  that  necessary  security  was  maintain^  tc  limit  penetration 
from  outside  (as  from  planted  trap  doors  or  viruses).  These  earlier  design  slips  could  lead 
to  damage  to,  or  even  grounding  of  an  entire  new  model/type  of  aircraft 

The  second  major  issue  is  one  of  life  cycle  suppoit  In  the  past  tlic  Navy  has  used 
field  activities  to  suppon  and  maintain  avionic;,  system  software  once  the  system  is  k 
production.  Typically  these  activities  developed  upgrades  based  on  fleet  requirements 
and  deliver  them  in  18’-24  months.  With  limited  rights,  the  Navy  may  be  seen  to  place 
itself  in  a  sole  .source  position  for  upgrades  to  the  COl^/NDI  software.  Depending  on 
the  kvcl  of  reuse,  the  Navy's  ability  to  respond  in  a  riiort  time  frame  to  fleet  n^uirements 
could  be  severely  limited. 

Code  reuse  has  been  invoked  as  u  means  to  reduce  costs  and  schedule  for  futrne 
prognuns.  Along  with  other  problems,  a  luck  of  consistency  in  the  use  of  "reuse" 
terminology  coupled  with  confusion  throughout  government  and  industry  in 
understanding  the  principles  inherent  in  making  and  incorporating  reusable  code  has 
produced  a  credibility  gulf  that  has  inhibited  the  maturing  of  reuse  technologies. 
Establishing  recognized  nomenclature  and  conventions  for  reuse  are  both  necessaiy  for 
government  and  industry  to  oollfx;tively  define  the  reuse  problems  and  identify  strategies 
to  begin  resolving  them. 
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9*3.9  Rapid  Prototyping 

Rapid  prototyping  serves  the  same  purpose  for  software  as  for  hardware.  It  is 
used  to  determine  if  questionable  or  key  assumptions  are  valid.  In  software,  as  in 
hardware,  it  is  also  used  to  determine  if  the  requirements  which  have  been  assumed  are 
valid  when  taken  together  as  a  group.  There  are  software  tools  such  as  STATEMATE 
available  now  which  allow  one  to  block  in  the  requirements  and  assumptions,  and 
determine  if  the  system  operates  in  a  correct  and  timely  fashion  under  those  assumptions. 
Even  more  important,  such  tools  allow  one  to  recover  from  assumptions  which  later 
prove  to  be  incorrect  by  providing  control  of  all  the  variables  in  a  software  system  and 
allowing  for  rapid  creation  of  alternate  paths  or  divisions  of  code  functionality  and 
subsequent  hardware  mappings. 


9-4  Compuier  Resources  Management 

The  development  of  computer  resources,  if  not  properly  managed,  will  result  in 
cost  overruns  and  schedule  slippages.  For  the  computer  software  portion  of  the 
development  to  be  successful,  a  structured  software  enginer^ring  discipline  must  be 
applied,  f'om  requirements  definition  through  fmal  test  and  accqttance,  sin^arly  to  those 
of  other  engineering  disciplines  in  the  engineering  community.  Both  govemsnent  and 
contractor  personnel  supporting  software  intensive  programs  must  have  riuffiicient 
technical  knowledge  of  the  software  engineering  development  process. 

Government  and  industry  alike  must  place  gieater  emphasis  on  the  preparation  for 
and  the  building  of  avionics  weapon  systems  which  require  large  scale;  software 
developments.  This  includes  training  of  personal,  establishing  software  and  design 
repositories,  engineering  and  software  environments,  integrated  design  processes, 
definitive  development  methods  and  procedures,  etc. 

In  the  past,  program  offices  have  underestimated  the  resources  and  costs 
associated  with  supporting  the  design,  development  and  suppon  of  software  systems. 
Significant  focus  has  at  times  been  placed  on  the  desim  of  software  itself,  but  not  on  the 
infrastructure  and  support  elements  (software  tools)  required  to  ensure  a  successful 
software  development. 


9-4.1  Process 

A  process  for  developing  software  must  be  developed  and  followed  in  order  to 
ensure  a  successful  software  development.  Many  actions  are  in  process  or  being  taken  to 
improve  program  software  development.  One  of  which  is  the  efforts  at  the  DoD  Software 
Engineering  Institute  (SEI).  SEl  has  developed  a  Capability  Maturity  Model  (CMM)  to 
add^ss  the  discipline  required.  The  CMM  addresses  the  disciplines/processes  which 
should  be  in  place  for  an  organization  to  produce  reliable  software  in  a  timely  and  cost 
effective  manner.  The  CMM  as  structured  has  five  levels  of  maturity  and  describes 
processes  which  must  be  in  place  to  reach  the  next  higher  maturity  level.  The  five  levels 
are  Initial  (Level  1),  Repeatable  G-evel  2),  Defined  (Level  3),  Managed  (Level  4),  and 
Optimizing  (Levei  5).  These  processes  must  be  integrated  into  the  overall  systems 
engineering  process  and  not  stand-alone  software  development  processes.  The  key 
benefits  that  an  organization  gain  by  raising  its  process  maturity  level  are  more  accurate 
predictions  for  sof^are  product  size,  cost,  quality,  and  schedule;  reduced  variability;  and 
improved  software  process  results,  ir.  addition,  an  organization  benefits  from  better 
technical  and  management  visibility  into  their  software  development  process.  More 
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accurate  predictions  are  most  useful  for  controlling  the  process  and  producing  products 
on  time  and  within  costs  projections. 

The  CMM  provides  an  invaluable  method  for  assessing  the  ability  of  a  software 
developer  to  satisfactorily  accomplish  a  software  development  effort  and  to  idehdfy  areas 
where  an  organization's  software  process  needs  improvements.  The  model  rests  on  the 
premise  that  software  process  maturity  is  a  credible  indicator  of  capability.  The  concept 
implies  that  the  productivity  and  quality  resulting  from  an  organization's  software  process 
can  be  improved  over  dme  and  presumes  that  improvement  comes  through  consistent 
gains  in  the  discipline  achieved  by  applying  the  CMM.  The  implication  is  that  as  an 
organization  gains  in  software  process  maturity  it  institutionalizes  its  software  process 
both  by  means  of  policies,  standards,  and  organizational  structure  and  by  building  a 
corporate  culture  that  supports  the  methods,  practices,  and  procedures  of  tlie  business.  In 
this  way,  the  software  process  (with  its  methods,  practices,  and  procedures)  endures  after 
those  who  originally  defined  them  have  gone. 

Finally,  each  higher  level  of  process  maturity  is  taken  as  indicating  both  greater 
control  of  an  organization's  software  process  and  greater  consistency  with  which  the 
process  is  applied  in  projects  throughout  the  organization.  Hence,  the  results  of  applying 
the  process  are  expected  to  be  more  predictable  at  successively  higher  levels.  The  C^IM 
serves  three  important  needs  of  a  software  development  organization.  It  provides: 

1)  An  underlying  structure  for  reliable  and  consistent  assessments. 

2)  A  framework  designed  to  help  software  organizations  characterize  the  state  of 

their  current  software  practices  in  consistent  terms,  set  goals  for  improtring 
their  software  process,  and  set  priorities  for  instituting  their  process  changes. 

3)  A  guide  to  organizations  planning  their  evolution  toward  a  culture  of 
engineering  excellence. 

A  well  defined  and  planned  software  measurement  program  is  requip.xl  to 
progress  through  the  levels  of  the  CMM.  Hie  basic  measurement  set  at  Level  2  is  size 
(lines  of  code),  effort  (labor  hours),  schedule  (calendar  time),  and  quality  (number  of 
defects).  Level  3  functions  add  to  the  basic  set  by  defining  and  institutionalbing  the 
organization's  software  development  process  and  on  estimating  for  a  project'.*^  defined 
software  process.  Level  4  then  focuses  on  further  identifying  and  quantifying  the 
organization's  software  development  processes,  selecting  process  and  produc*  data  to  b^; 
collected,  analyses  to  be  performed,  process  and  product  metrics  to  be  used  in  nanaging  a 
project,  and  derining  quantitative  goals  for  product  and  process  quality.  Level  5  focuses 
on  the  optimizing  process  by  incorporating  the  lessons  learned  ^m  continuing  process 
measurements  and  development  experience. 
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9-42  Metrics 

A  developer  must  establish  project  goals  and  software  metrics  for  project  control 
and  process  improvement.  Software  measurables  are  directly  observable  quantities  that 
you  can  count,  such  as  lines  of  code,  or  that  you  can  otherwise  measure,  such  as  labor 
hours  and  labor  months.  A  softwtue  measurement  is  a  number  assigned  to  an  observable, 
;le.,  a  quantitative  assessment,  of  a  software  process  or  product  A  software  metric  is  a 
number  assigned  to  a  quantifiable  concept  that  relates  to  a  software  product  or  to  the 
process  that  created  it.  A  metric  is  not  always  observable.  A  metric  may  be  a  single 
measurement  (lines  of  code)  or  it  may  be  a  function  of  one  or  more  measurables  (lines  of 
code  per  labor  months).  The  main  categories  of  metrics  are: 

1)  product  size  -  counts  of:  initial,  undefined,  added,  and  deleted  requirements; 
design  statements,  document  pages,  process  "bubbles”,  data  entities,  and 
boxes  or  arrows  in  hierarchical  input-output  chans:  source  statements, 
comments,  function  points,  object  code  instmetions,  and  words  of  memory; 
tests,  test  procedure  steps,  and  pages  of  test  documentation;  entities  such  as 
CSCIs,  CSCs,  eSUs,  algorithms,  function  and  feature  points,  inputs/outputs, 
logical  fUes,  internal  interfacing  hardware  components,  and  external  system 
interfaces;  documents,  types  of  documents,  and  pages  of  documentation;  and 
status  of  ECPs,  STRs,  authorized  and  staffed  personnel  positions,  and  percent 
of  budget  spent. 

2)  product  costs  -  initial  estimate  and  final  actuals,  budgets  and  amount  expended 

3)  schedule  -  elapsed  times  in  weeks,  months,  or  years 

4)  quality  -  number  of  defects,  defects  per  unit,  cost  per  defect,  average  number 
of  days  to  fix  defects,  effort  to  verify  the  product,  effort  to  reuse  the  product  as 
a  function  of  ef^f^ort  to  develop  the  product,  number  of  unique  inputs  and 
outputs  and  the  number  of  assignment  statements,  etc. 

5)  product  application  environment  -  system  resources  -  real-time  limits, 
complexity,  throughput,  memory,  input/output 

6)  development  environment  characterizatioji  -  modem  programming 
practices/methods,  ri^  management,  suppor^g  workstations,  software  tools, 
requirements  stability,  process  stability,  simultaneous  haidware/software 
development,  standards  enforcement,  fype  of  contract 

7)  development  constraints  •  severify  of  cost,  schedule,  aitd  staffing  constraints, 
and  development  personnel  characterization  (experience,  application 
familiarity,  and  language  familiarity) 

Those  who  will  use  information  and  what  information  is  required  must  be  a 
foremost  consideration  in  arriving  at  the  specific  metric(s)  to  be  collected.  Many 
different  users  of  information  exist.  A  pven  user  will  only  be  interested  in  collecting  and 
analyzing  those  metrics  that  apply  to  his  areas  of  interest  Users  of  informa'ion  may  f^ 
into  one  or  more  of  the  following  gro  jps:  software  engineering  process,  softwarr;  quality 
assurance,  systems  engineering,  program/project  management,  software  management, 
software  engineering,  software  development,  software/system  test,  and 
accounting/finance. 
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Arriving  at  the  actuai  metrics  to  be  collected  is  aided  if  the  following  process  is 
used.  State  the  goal(s)  of  the  development.  Use  the  goals  to  determine  who  are  the  users 
of  the  information  are  and  what  they  need  to  know.  The  users  of  the  infoimadon  will  be 
both  contractor  and  government  personnel.  Having  determined  the  information  which 
will  be  required,  decide  what  questions  users  arc  going  to  ask  to  determine  that  the 
goal(s)  have  been  satisfied.  The  specific  metric  that  must  be  collected  and  the  things  that 
are  to  be  measured  can  now  be  detennined.  The  method(s)  for  collecting  the  metric(s) 
can  now  be  established. 


9-4  J  Software  Experience  Database 

Every  organization,  including  contractors  and  government,  should  establish  and 
maintain  a  software  experience  database.  This  database  should  contain  the 
measurements,  metrics,  and  other  information  that  can  be  used  to  support  project  control 
and  software  process  improvement.  This  database  can  also  be  used  to  support  software 
CIs  which  have  entered  the  PDSS  phase. 

The  establishment  and  maintenance  of  this  database  should  be  mandated  by  and 
supported  at  the  highest  organizational  level.  The  infonnation  contained  in  the  dsuabase 
can  be  used  to  form  the  basis  for  improving  software  standards,  improving  the  plaiming 
and  proposal  pr^ss,  estimating  and  managing  costs,  developing  and  refining  estimation 
models,  determining  size  and  unit  cost  of  future  software,  evfiuating  product  quality, 
managing  risk,  and  improve  the  development  process. 

The  softv/are  experience  database  is  an  importakit  component  of  the  quantitative 
software  management  process.  It  is  a  powerful  tool  for  improving  organizational 
performance.  Infoimadon  contained  in  the  database  should  be  readily  available  to  all 
organizational  elements;  participating  in  the  avionics  system/software  development 
process. 


9-5  Software  Science  and  Technology  Thrusts 

It  is  imperative  that  NAVAIR  participate  in  Science  and  Technology  Thrusts 
which  are  being  pursed  to  insure  that  NAVAIR  stays  abreast  of  and  can  influence  current 
technok^i^y  developments.  Areas  in  which  NAVAIR  should  be  concerned  include 
software  and  systems  engineering,  human-computer  interaction,  artificial  intelligence, 
parallel  and  heterogeneous  distributed  systems,  real-time  fault-tolerant  software,  high- 
assurance  software,  reusing  software,  software  security,  advancing  programming 
techniques,  re-engineering,  improving  software  maintenance,  and  improving  software 
engineering  environments.  Work  in  these  areas  in  underway  both  in  industry  and  the 
government  through  ongoing  efforts  like  "Software  Technology  for  Adaptable,  Reliable 
Systems  (STARS).  NAVAIR  should  participate  in  the  activities  underway  at  the 
Software  Engineering  Institute  (SEI),  the  Software  Productivity  Consortium  (SPC),  and 
the  Software  Technology  Suppon  Centei’  (STSC), 
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Throughout  this  Review,  industry  respondents  emphasized  the  important  role 
played  by  Systems  Engineering  (SE)  as  a  major  contributor  to  effective  avionics  systems 
development.  Although  most  of  the  major  aerospace  firms  that  contributed  to  the  review 
place  a  great  deal  of  inqjortance  on  “the  SE  process",  theiv  is  a  great  deal  of  variability  in 
how  SE  is  defined  and  actually  applied  by  these  firms.  This  volume  provides  a  summary 
overview  of  the  SE  Process  (SEP)  as  taught  at  the  Dcfen.se  Systems  Management  C^oUsge 
and  as  currently  applied  by  several  major  progranos  in  the  Army,  Air  Force  and  Navy.  An 
introductory  discussion  of  today’s  current  role  and  tomorrow's  future  potential  of  utilizing 
SE  to  develop  affordable,  high  performance  avionics  systems  is  also  provided  to  stimulate 
interest.  „ 

This  volume  outlines  the  basic  elements  of  SE  witii  focused  emphasis  on  its 
application  to  the  specific  development  of  avionics  systems.  It  is  intended  to  highlight  the 
hi^ly  important,  expanding  role  of  SE  to  more  efficiently  and  effectively  develop  modem 
avionics  systems. 
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1-0  BACKGROUND 


The  development  of  large  and  complex  systems  has  given  rise  to  an  increased 
awareness  of,  and  need  for.  Systems  Engineering  (SE).  This  has  been  especially  important 
in  the  development  of  DoD  weapon  systen^  because  of  the  need  to  inject  new  technology 
into  both  new  and  existing  systems,  in  a  manner  that  controls  the  inherent  risks.  The 
difflculties  experienced  in  evolving  new  systems  has  led  to  the  development  of  speciric 
methods  and  techniques  within  SE  in  an  attempt  to  provide  better  insight  and  control  mto 
the  development  and  management  process. 


Importance  of  Systems  Engineering  (SE) 

A  major  finding  of  this  review  is  the  critical  requirement  for  a  resurgence  in 
emphasis  on  SE.  In  one  sense  SE  is  considered  to  be  nothing  more  than  “good,  common 
sense”  engineering  practice.  In  a  more  formal  sense,  SE  describes  the  conqrlete  process  of 
engineering  as  applied  to  system  development.  SE  is  the  primary  technical  methodology  by 
which  customer  needs  are  translated  into  a  balanced  set  of  product  and  process 
descriptions.  A  majority  of  the  corporations  that  participated  m  the  review  placed 
considerable  emphasis  on  the  need  for  a  rigorous  SE  approach  as  a  basis  for  effective 
systems  development.  SE  is  undergoing  a  revolution  today,  primarily  because  it  is 
recognized  that  many  earlier  approaches  to  the  engineering  of  systems  development  are 
inadequate  for  the  complex,  software  intensive  systems  of  today.  An  approach  is  needed 
that  considers,  in  addition  to  product  operability,  all  down  stream  presses  such  as 
producibility,  testability,  deployability,  supportability  and  disposability  in  its  early 
development  efforts.  In  addition,  the  revolution  is  enhanced  by  the  avaUabUity  of  a  large 
number  of  computer  based  tools.  Tools  are  available  and  arc  continuing  to  evolve  that 
support  virtually  all  activities  within  Systems  Engineering' 

One  stated  purpose  for  this  review  is  to  predict  the  avionics  architectures  that  the 
Navy  will  deploy  10  to  20  years  hence.  We  are  unable  to  make  these  predictions  explicitly 
because  of  uncertainty  over  the  exact  impact  of  new  and  emerging  technologies.  No  one 
can  make  these  predictions  explicitly!  However,  during  the  course  of  this  review,  it  has 
become  clear  that  the  process  by  which  future  architecture  alternatives  are  conceived, 
synthesized,  analyzed  and  selected  is  just  as  important  a  factor  as  the  specific  technologies 
ereployed.  Desij^ating  this  approach  “Systems  Engineering"  we  are  sue  in  saying  that  if  a 
well  defined  avionics  SE  appi^ch  is  in  place,  and  if  the  available  avionics  architectural 
alternatives  are  objectively  considered  tiirough  this  process,  the  Navy  will  obtain  avionics 
architecture  solutions  that  optimally  balance  emerging  technologies  and  the  use  of 
Commercial  Off  The  Shelf  (COTS)  products  against  the  practical  constraints  imposed  by 
fleet  supportability  and  affon^bility  requirements. 


Rote  of  MIL-STD-4993 

The  defining  document  for  the  application  of  SE  to  the  development  of  military 
systems  is  MIL-STD>499B  entitled  ‘^Systems  Engineering”.  A  renewed  emphasis  on  SE  is 
reflected  in  the  title  of  this  Standard,  changed  from  “Engineering  Management"  of  the 
predecessor  M1L-STD-499A.  This  standard  provides  a  comprehensive  guide  to  the  SE 
Process  to  be  applied  to  the  development  of  defense  systems.  The  current  revision  (draft 
dated  6,  May  92,)  is  waiting  fin^  release  but  has  been  fully  reviewed  and  is  being 
referenced  extensively.  Although  not  officially  released,  this  document  has  achieved  de 
facto  recognition  as  the  military  SE  guide.  This  revision  is  considerably  updated  and  is 
cemsistent  with  recent  SE  thought  and  current  military  practice. 
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MIL-STD-499B  mi'st  be  considered  a  general  standard  or  “framework"  for  the 
application  of  SE  to  the  acquisition  of  militaiy  systems. 

Application  of  SE  to  military  avionics  requires  background  information  and 
guidance  specifically  tailored  to  the  application.  Systems  Engineering,  as  delineated  in 
M1L-STD-499B  is  designed  to  function  in  accordance  within  event  based  milestones 
imposed  by  the  acquisition  life  cycle.  The  process  requires  performance  of  certain  specific 
tasks  for  successive  development  levels  (concept,  system,  subsystem, ...)  and  the  decision 
events  related  to  progressing  from  one  level  to  the  next  Technically,  application  of  the  SE 
process,  as  defmed  in  MIL'STD-499B.  must  be  customized  to  deal  specifically  with 
avionics  system  needs  and  with  current  technical  trends  in  militaiy  avionics. 


Focus  on  Open  Systems 

Although  it  is  recognized  that  an  avionics  system  is  but  a  subsystem  of  the  total 
aircraft  system;  it  is  a  costly  subsystem  and  therefore  it  is  essential  to  take  advantage  of  the 
trend  toward  Open  System  Architectures  (OS A).  Avionics  application  of  SE  appropriate 
for  the  present  day  must  accommodate  this  trend.  The  architectures  chosen  for  avionics 
systems  must  be  well  defined  and  suitable  for  the  growth  and  evolution  required  by 
increasingly  complex  system  needs  for  advanced  avionics.  The  aircraft  systems  envisioned 
should  place  considerable  emphasis  on  the  use  of  modular  packaged  avionics,  llie  use  of  a 
modular  OSA  provides  a  physical  framework  for  the  development  of  advancol  avionics 
systems  while  providing  a  convenient  basis  for  technology  insertion  and  evolutioniuy 
growth  (at  the  module  level).  A  modular  Avionics  framework  utilizing  OSA  provides  a 
means  of  mitigating  technology  obsolescence  while  providing  the  military  an  opportunity 
to  leverage  commercial  technology  trends  and  enhance  "economy  of  scale"  potentials 
through  "dual  use"  technology  application. 

An  up  to  date  tailoring  of  MIL-STD-499B  for  Avionics  should  establish  the  basis 
for  the  application  of  a  family  of  "architecture  doming"  Open  Systems  Architecture 
standards. 


1-1  The  Role  and  Scope  of  Systems  Engineering 

The  essential  role  of  SE  in  the  systems  acquisition  process  is  to  ensure  that  the  right 
things  get  done  during  the  development  of  new  defense  systems,  or  during  any  upgrade  of 
already  frelded  systems.  By  employing  SE  methods  a  total  system  design  solution  is 
developed  that  incorporates  all  down-stream  life-cycle  needs  (e.g.,  manufacturing, 
verification,  deployment,  operations,  suppon,  training,  and  disposal)  at  an  affordable 
balance  of  performance,  risk,  cost  and  schedule.  SE  is  die  primary  technical  methodology 
by  which  customer  needs  are  translated  into  a  balanced  set  of  product  and  process 
descriptions.  These  descriptions  should  enable  a  quality  system  to  be  produced  and 
deployed  that  satisfies  the  operational  need  and  is  affordable,  operationally  suitable  and 
operationally  effective. 
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1-1.1  Systems  Engineering  (SE)  Definition 

'fhere  tOC  mar<y  general  definitions  offered  in  the  littrature  to  cover  the  scope  of 
Systems  Engineering.  The  definition  in  Mn^-SID-dQQB  is  comprehensive,  linking 
together  the  many  elements  of  Systems  Engineering. 

Systems  Engineering:  "An  interdisciplinary  approach  to  evolve  and  verify  an  integrated 
and  life-cycle  balanced  set  of  system  product  and  process  solutions  that  satisfy  customer 
needs.  Systems  Engineering:  (a)  enconytasses  the  scientific  and  engineering  efforts  related 
to  the  development,  mamtfacturing,  verification,  deployment,  operations,  support,  and 
di^osal  of  system  products  and  processes.,  (b)  d^elops  needed  user  training  equipment, 
procedures,  and  data  (c)  establishes  and  maintains  configuration  management  of  the 
system,  (d)  develops  work  breakdown  structures  and  statements  of  work,  and  (e)  provides 
information  for  management  decision  making." 

SE  is  required  during  each  level  of  development  and  during  each  acquisition  and 
support  phase  of  the  life  cycle.  The  pimciples  of  SE  apply  to  all  system  developments 
whether  large  or  small,  major  or  non-major,  new  development,  modifications  or  upgrades, 
and  for  single  or  multiple  procurements.  Properly  performed,  SE  requires  full 
consideration  of  all  the  technical  disciplines  involved  in  Ae  system  developi^nt  11118 
mandates  participation  by  interdisciplinary  teams  of  engineers,  concerned  with  design, 
development,  production,  testing,  logistics  and  training,  and  by  iq^propriate  representatives 
from  contracts,,  budgeting,  finance,  legal,  marketing  ai^  the  using  community. 

Although  the  need  for  SE  is  universal  for  any  engineering  development,  its 
application  is  crucial  for  the  effective  development  of  luge  and  complex  systems 
characteristic  of  modem  integrated  avionics. 


1-2  Avionics  Application  of  Systems  Engineering 

Beyond  the  above  definition,  Systems  Engineering  applied  to  advanced  integrated 
avionics  systems  development  must  have  certain  properties. 

It  must  be  kept  in  mind  that  the  avionics  system  is  a  subsystem  of  a  larger  aircraft 
system.  Thr  needed  functions  of  the  avionics  subsystem  should  be  defined  by  a  "Top 
Down"  p^ess.  Once  the  avionics  functions  are  defried,  then  the  aviraucs  system  planning 
must  begin  at  the  top  and  flow  down  to  the  various  levels.  This  requires  that  there  be  a  top 
level  concept  development  which  is  the  architectural  model  ("vision")  selected  for  the 
system  to  be  develop^.  This  systems  vision  may  change  due  to  constraints  found  during 
the  development  process,  however  without  the  initial  top  level  modelMsion,  any  chance  of 
producing  a  balanced  avionics  system  design  is  virtually  non  existent  A  "Top  Down” 
approach  is  generally  advocated  for  Systems  Engineering.  The  complexity  and  interactive 
nature  of  modem  avionics  systems,  within  a  larger  airendt  system  context  makes  "'fop 
Down"  application  a  necessity. 

The  scope  of  modem  avionics  systems  (large  scale  and  con^lex)  leads  to  the  use  of 
multi-disciplinary  teaming  for  system  development  The  concept  of  multi-disciplinary 
development  teams  is  relatively  new,  but  has  now  become  inherent  in  modem  Systems 
Engineering  practice.  The  interactive  nature  and  complexity  of  integrated  avionics  r^uircs 
teaming  to  establish  needed  information  flow  among  the  various  engineering  disciplines 
and  their  practitioners  and  is  necessary  for  effective  coordination  and  proper 
implementatirai  of  Systems  Engineering. 
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2-0  SYSTEMS  ENGINEERING  POLICY 

The  importance  of  Systems  Engineering  is  emphasized  throughout  the  Defense 
Department  acquisition  life  cycle.  DoD  instruction  DODI  5000.2  “  Defense  Acquisition 
Management  Policies  and  Procedures",  establishes  the  need  for  an  integrated  framework 
for  translating  mission  needs  into  a  stable,  affovdable  program  that  meets  operational  needs. 
It  calls  for  a  rigorous  event-driven  management  process  for  acquiring  products, 
emphasizing  certain  key  Systems  Er  gineering  tasks. 


2-1  Specific  Systems  En, gineering  Responsibilities 

DODI  5000.2  In  Pan  6A,  spells  out  specific  Systems  Engineering  responsibilities 
to  conduct  in  accordance  with  Mii-lStd499.  These  include:  applying  a  comprehensive, 
iterative  technical  process  throughout  the  system  life  cycle;  assessing  progress  with 
periodic  technical  reviews  and  audits,  transitioning  applicable  technologies  into  tlie 
development;  managing  risks;  verifying  requirements;  integrating  specialty  requirements; 
maintaining  configuration  and  data  management;  and  utilizing  a  work  breakdown  structure. 
The  specific  Systems  Engineering  tasks  identified  include  the  following: 


(1)  Translating  Identified  Needs  into  Design 

This  task  is  extremely  important  in  assui  ing  that  ident^ed  needs,  through  the 
explication  of  the  Systems  Engineering  process,  are  translated  into  ^sign 
requirements.  Generally  known  as  Requirements  Analysis,  this  task  is  extremely 
important  in  assuring  that  the  systems  development  is  designed  to  the  right 
technical  requirements.  In  the  past,  failure  to  perform  this  task  properly  has  led  to 
failed  system  developments. 

(2)  Transitioning  Technology  front  the  Technology  Base  to  Product  and 
Process  Applications. 

This  is  an  important  task  to  ensure  that  emerging  technologies  are  effectively 
(XpUed  to  Naval  avionics.  Failure  to  effectively  transition  technology  can  result  in 
premature  obsolescence  as  avionics  requirements  continue  to  stress  the 
technology  base.  This  task  is  further  complicated  by  the  present  emphasis  on  the 
use  of  Commercial  Off  The  Shelf  or  COTS  technology.  By  following  Systems 
Engineering  guidelines  for  avionics,  a  proper  evaluation  can  be  made  that  ensures 
an  intelligent  balance  between  the  use  of  COTS  and  new  technologies. 

(3)  Establishing  A  Technical  Risk  Management  Program. 

This  task  emphasizes  that  a  major  part  of  the  Systems  Engineering  effort  is  that  of 
managing  technical  risk.  It  is  required  that  technical  risks  be  identified, 
quantified,  and  impacts  assessed  and  dealt  with  throughout  the  acquisition  cycle. 
The  Systems  Engineering  process  includes  risk  management  as  an  integral 
element  of  product  and  process  development  and  requires  the  management  qf  risk 
to  acceptable  levels.  Technical,  cost,  schedule  and  other  program  risks  are 
addressedm  each  technical  and  program  review.  Because  advanced  avionics 
require  new  and  emerging  technologies  to  satisfy  technical  requirements,  the 
Avionics  Program  Manager  is  faced  with  a  very  difficult  task  in  skillfully  trading 
off  performance  gains  versus  technical  risk. 
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(4)  Verifying  that  Item  Design  Meets  Established  Requirements. 

This  task  requires  that  c  product  (item  design)  undergo  a  comprehensive 
verification  process  that  is  established,  implement ,  and  controlled  as  an  integral 
part  of  the  systems  engineering  ^ort.  This  task  requires  a  progressive 
verification  of  the  system  developrMnt  from  parts,  materials  and  subprocesses  up 
through  totid  system  products  and  processes.  This  is  an  extremely  important  part 
cf  the  process  and  is  made  especially  difficult  for  ad' anced  avionics  systems 
development  because  of  the  extensive  reliance  on  software.  St  tisfactory  Software 
metrics  and  test  routines  comprise  a  major  part  of  the  aviosJes  verification 
process.  This  is  often  made  more  difficult  because  for  major  systems  the 
Hardware  and  Software  is  often  developed  in  parallel,  with  the  result  that  the 
system  Hardware  is  usually  not  complete  and  therefore  not  available  to 
demonstrate  the  software  during  the  development  process. 

2-2  Specified  Tools  ~ 

The  two  specific  tools  that  are  spelled  out  in  DODI 50002  to  assist  management  of 
the  Systems  Engineering  effort  are  a  Systems  Engineering  Management  Plan  (SEMP)  and 
Technical  Performance  Measurement  (TPM).  Effective  use  of  these  tools  is  important  to 
the  Systems  Engineering  Process  and  wili  be  described  in  a  later  section. 

(see  also:  Volume  1.  section  9-3.5) 
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3-0  THE  SYSTEMS  ENGINEERING  FRAMEWORK 


Sysrems  Engineering  involves  developing  system  descriptions  one  level  at  a  time; 
first  as  a  concept,  next  as  a  system,  and  then  as  a  set  of  subsystems.  More  and  more 
descriptive  detail  is  provided  in  successive  levels  of  development.  After  each  level  of 
development,  technical  reviews  are  conducted  to  determine  the  maturity  of  the 
development,  the  affordability  of  the  approach,  and  the  readiness  to  proceed  to  the  next 
level  of  development. 

Systems  Engineering  is  fundamentally  a  problem  solving  activity.  The  problem  that 
is  solved  is  a  milit^  need  for  a  new  or  improved  capability  by  a  new  or  modified  system. 
Systems  Engineering  defines  this  problem  by  determining  the  functional  and  performance 
requrn'ments,  constraints,  measures  of  effectiveness,  udlizadon  environments,  and  external 
interfaces.  Tlus  problem  defmidon  is  then  translated  into  solution  criteria  by  decomposing 
problem  level  functions  to  lower  level  functions  commensurate  with  the  level  of 
development  and  then  allocating  problem  level  performance  requirements,  constraints,  etc. 
to  the  lower  level  functions. 

Next,  the  Systems  Engineering  approach  determines  alternative  solutions  for  each 
defined  function  and  by  means  of  an^ysis  selects  the  best  solution  to  satisfy  total  system 
needs.  After  each  solution  determination,  a  verification  is  made  to  demonstrate  that  the 
problem  requirements  are  indeed  satisfied  by  the  solution  selected.  The  solutions  are 
described  in  appropriate  documents  (specifications  and  drawings)  which  provide  details  for 
the  next  level  of  development  or  for  manufacturing  of  the  products  described. 

It  is  important  to  emphasize  that  Software  development  is^iart  of  the  total  Systems 
Engineering  development  and  should  not  be  consider^  as  a  separate  area.  This  is  an 
important  point  since  treating  the  Hardware  development  and  the  Software  development  as 
two  distinedy  different  isolated  efforts  has  led  to  major  cost  overruns  and  program  failures. 
Systems  Engineering  is  an  umbrella  for  all  the  engineering  efforts  including  the  engineering 
specialties  grouped  under  Supportability.  A  recommended  approach  to  ensure  that  proper 
coordination  and  balance  between  the  many  engineering  tasks  is  established  and 
maintained,  is  to  use  multi-disciplinary  Integrated  Product  Teams  (IPTs)  throughout 
development 

In  essence.  Systems  Engineering  provides  a  framework  for  development  that  is 
balanced  against  the  primary  functions  that  a  system  must  satisfy.  The  Systems 
Engineering  framework  is  shown  in  Hgure  3-0  (from  MIL-STIM99B). 
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As  shown  in  Figure  3-0,  the  original  input  to  the  Systems  Engineering  Process  is 
the  customer  defined  needs  statements  ^  the  system.  Any  system  can  be  described  as  a 
set  of  components  woriong  together  with  a  common  objective  of  performing  a  function  in 
response  to  a  designated  need.  The  components  of  a  system  may  consist  of  any 
combination  of  people,  processes  and  products  that  satisfies  the  designatnl  Action.  As 
in^cated  in  the  figtm,  the  customer  n^ds  statements  must  be  considered  against  the  ei^t 
prim^  systems  functions.  The  implication  of  this  dqpiction  is  to  emphasize  that  all 
fun^ons  are  to  be  considered,  not  just  (tevelopment,  so  that  a  functional  balance  is 
achieved  as  the  system  requirements  are  evolved.  Each  layer  of  the  Systems  Engineering 
Process  r^ramework  represents  a  phase  of  the  ac^isition  life  cycle.  As  each  layer  is 
traversed  the  elements  of  the  Systems  Engineering  I^ess  are  peiformed  considering  the 
eight  primary  functions  throughout.  As  each  acquisition  phase  is  completed,  the  Systems 
Engineering  outputs  become  the  inputs  to  the  next  phase.  As  each  successive  phase  is 
completed  the  products  of  the  Systems  Engineering  process  become  more  conqiletely 
defined  and  matured. 
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3-1  Systems  Engineering  Process 

The  definition  for  the  Systems  Engineering  process  (from  Mil-Std-499B)  is  as 
follows: 

Systems  Engineering  Process:  "A  comprehensive,  iterative  problem  solving  process 
that  is  used  to  (a)  tran^orm  validated  customer  nee^  and  requirements  into  a  life-cycle 
balanced  solution  set  of  system  product  and  process  designs,  (b)  generate  iirformationfor 
decision  makers,  and  (c)  provide  itrformationfor  the  next  acquisition  phase.  The  problem 
and  success  criteria  are  defined  through  requirements  analysis,  functional 
anatysislallocation,  and  systems  analysis  and  control.  Alternative  solutions,  evaluation  of 
those  alternatives,  selection  of  the  best  life-cycle  balanced  solution,  and  the  description  of 
the  soluiim  through  the  design  package  are  accomplished  through  synthesis  and  systems 
analysis  and  control". 

The  Systems  Engineering  Process  is  applied  for  each  level  of  development  of  the 
system  (concept  derinition,  system  definition,  and  subsystem  definition)  to  pirovide  a  low 
ri^  transition  from  development  to  production.  These  levels  of  development  are  timed  to 
coincide  with  the  DODD  5000.1  and  DODI  5(X)0.2  acquisition  management  system 
controlled  by  the  key  milestone  events  of  the  program  and  the  Program,  Planning  and 
Budgeting  System  (PPBS). 

The  Systems  Engineering  Process  provides  a  comprehensive,  simultaneous 
(concurrent)  engineering  approach  for  the  development  of  the  products  and  processes  of  the 
total  system  (design  in  all  down  stream  processes  needed  to  produce,  verify,  distribute, 
operate  and  support  the  desired  operational  system,  including  personnel  training  and 
disposal  of  process  by-products  and  spent  products).  Tiie  Systems  Engineering  Process  is 
applied  recursively,  and  in  an  iterative  manner,  throughout  system  development  It  is 
iterative  in  that  the  activities  of  the  piocess  are  not  linear  but  highly  interactive  to  develop 
the  best  balanced  set  of  process  and  process  descriptions  technical  Data  Package) 
appropriate  for  that  level  of  development  In  addition  to  being  comprehensive  and  iterative 
for  each  application,  the  Systems  Engineering  Process  (SEP)  is  also  recursive  when 
applied  to  successive  levels  of  development.  Because  of  its  recursive  nature,  value  is 
added  by  each  iqiplication  in  that  the  ou^ut  of  one  level  is  used  as  an  input  to  the  next  level. 
Thus  the  definition  of  the  system  and  its  subsystems  mature  with  successive  applications  of 
the  SEP  into  a  stable,  affoi^hle  design. 

The  Systems  Engineering  process  (as  depicted  in  MIL-STD-499B)  is  presented  in 
Figure  3-1,  listing  the  major  activities  included  in  each  of  the  four  principal  tasks.  The 
figure  indicates  the  iterative  nature  of  the  process  as  shown  by  the  f^badc  paths  around 
certain  tasks.  As  the  design  details  are  solidified,  feedback  to  the  input  of  each  process  step 
is  used  to  verify  consistency  of  the  design  to  requirements. 


pagc9 


Advanced  Avionics  Architecture  &,  Technology  Review 


Figure  3-1  The  Systems  Engineering  Process  (Source:  MILrSTD-499B) 

3-2  The  Principal  Systems  Engineering  Activities  of  the 
Systems  Engineering  Process. 

As  described  in  MIL-STD-499B,  there  are  four  major  activities  performed  ^  part  of 
the  Systems  Engineering  Process.  These  activities  are  tiie  following:  (1)  Requirements 
Analysis,  an  activity  winch  translates  customer  requirements  into  discrete  functions;  (2) 
Functional  Analysis,  an  activity  which  decomposes  all  functions  imd  allocates  then  to 
domains  within  a  functional  architecture  of  the  system,  (3)  Synthesis,  an  acti^tity  which 
defines  hardware  and  software  items  and  assigns  the  reqidred  functions  to  those  items:  and 
(4)  Systems  Analysis  and  Control,  an  activity  which  includes  the  engineering  numagement 
of  system  development,  the  balance  of  the  ottier  Systems  Engineering  Process  Outputs  and 
selection  of  the  "best"  candidate  from  physical  and  system  architectures  proimsed  as 
alternatives. 

3-2.1  The  Primary  Tasks  of  the  Systems  Engineering  Process. 

The  Systems  Engineering  Process  as  defmed  in  M[L-S'IT)-499B  involves  the 
following  four  tasks: 

(1)  Requirements  Analysis, 

(2)  Functional  Analysis, 

(3)  System  Synthesis, 

(4)  System  Analysis  and  Control  (Balance) 
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The  activities  within  these  four  tasks,  take  customer  inputs  to  the  process  and 
translate  them  into  the  desired  process  outputs. 


3-2.2  Inputs  To  The  Process  :  Requirements 

Customer  Requirements  are  broad  in  scope.  They  include  mission  needs, 
operational  environments,  and  various  constraints  placed  ttpon  the  development  (such  as 
costs,  development  time,  the  mandated  use  of  legacy  equipment,  etc.).  Other  parameters 
which  can  be  considered  as  requirements  (or  design  constraints)  include  various  Measures 
Of  Effectiveness  (MOEs)),  and  the  need  to  satisfy  specific  support  environment 
requirements.  Specifically,  the  Supportability  requirements  for  Carrier  operation 
distinguish  the  ne^s  of  Navy  aircraft  from  those  of  the  other  Services.  Inputs  may  include 
the  output  from  a  prior  level  of  development  (c.g.,  draft  or  approved  speciEcadons),  the 
Requirements  provided  from  Technical  Reviews  or  from  Program  Decision  Memoranda,  as 
well  as  new  or  revised  customer  requirements.  In  early  phases  of  uhe  program, 
requirements  are  often  very  general  and  are  easily  and  often  miodified.  As  the  program 
proceeds  through  the  acquisition  process  these  requirements  become  more  firmly 
established  and  become  the  basis  for  the  preparation  of  contracts  for  the  acmal  product 
development 


3-2.3  Requirements  Analysis 

Requirements  Analysis  generates  information  on  what  the  system  must  do  and  how 
well  it  must  do  it.  Process  inputs  provide  the  source  from  which  these  top  level  technical, 
functional  and  peiformanre  r^uirements  are  generated.  In  essence.  Requirements  Analysis 
defines  the  problem.  Through  Requirements  Analysis,  we  establish  utilization 
environments,  and  design  constraints  (e.g.,  system  level  functional  and  performance 
requirements  and  external  interfaces)  in  quantifiable  characteristics  and  tasks  for  the  eight 
prima^  functions  (e.g.,  development,  manufacturing,  verification,  deployment, 
operations,  support,  training  and  disposal). 


3-2.4  Functional  Analysis 

Through  Functional  Analysis,  the  functional  architecture  of  the  system  is  defined. 
This  is  done  by  identifying  successive  levels  or  sub  functions  necessary  to  accomplish 
upper  level  functions.  The  sub  functions  are  arrayed  in  a  functional  architecture  which 
shows  relationships  and  interfaces.  Upper-level  perfonmnee  requirements  are  flowed 
down  and  allocate  to  lower-level  sub  functions.  With  each  level  of  development  one  or 
more  sub  functional  levels  are  added  to  tlie  functional  architecture  based  on  the  physical 
solutions  generated  from  the  prior  application  of  the  SE  Process. 


3-2.5  Synthesis 

Through  Synthesis,  the  functional  architecture  is  translated  into  a  physical 
architecture.  Groups  of  functions  from  the  functional  architecture  form  (Configuration 
Items  (CIs).  Synthesis  activities  generate  alternative  physical  solutions  for  each  CT.  A  Cl 
can  be  made  up  of  one  or  more  of  the  following  system  elements:  hardware,  software, 
data,  personnel,  facilities,  material,  services  or  techniques.  Ibese  system  elements  provide 
physical  building  blocks  that,  in  combination,  make  up  the  physical  architecture  of  the 
system.  Done  rigorously,  the  system  Synthesis  process  is  supported  by  the  extensive  use 
of  computer  based  trade  studies  and  system  efiectiveness  analyses. 
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Recommenmtiqns  from  this  Review  strongly  support  the  use  of  Open  Systems  Standards 
as  the  "buiiding  block"  elements  and  interfaces  employed  in  synthesizing  systems  in  order 
to  expand  the  Uidustrial  supplier  base.  The  complexity  of  modern  avionics  systems 
requires  a  major  utilization  of  computer  models  arid  simulation  tools  to  accomplish  the 
Synthesis  function. 

3 >2. 6  System  Analysis  and  Control  (Balance) 

Thi  task  provides  the  assessment  and  control  necessary  to  manage  the  development 
process.  1'lds  task  is  essentially  one  of  achieving  an  effective  balakace  between  cost, 
schedule,  performance  and  risk  suitable  for  the  spe^c  development  To  accon^lish  this 
task,  the  ^velopmrnt  team  makes  m-e  of  1‘rade  Studies,  Effectiveness  Analysis,  Risk 
Management,  Configuration  Management,  Interface  Management,  Data  Management, 
Performance  Based  ProgreksS  Measurements(thiough  use  of  SEMS,  TPM,  Technical 
Reviews)  and  other  necessary  activities  to  ensure  development  balance  and  control.  This 
task  covers  the  activities  necessary  to  manage  system  development  and  the  conduct  of  the 
systems  engineering  process.  The  pcrformance  of  this  task  is  determined  by  the  use  of 
pi^ormance  based  progress  measurements  that  provide  indicators  of  how  well  system 
develppment  is  progressing. 

The  Systems  Engineering  aedvides  included  in  the  Systenos  Analysis  and  Control 
task  of  the  Systems  Engineering  Process  are  described  below.  Successful  applicadon  of 
these  aedvides  lead  to  a  balanc^  set  of  product  and  process  soludons  to  the  dm^elopment 
problem. 

Trade  Studies  -  A  trade  study  (also  called  trade-off  analysis)  is  a  process 
whereby  viable  altemadves  are  examined  to  determine  which  is  preferr^  The 
results  of  this  iteradve  process  are  used  to  support  technical  decisions  concerning 
system  concepts,  requirements  or  design  soludons.  The  trade-off  methodology 
provides  an  approach  to  decision  making  diat  is  rational,  objective,  and  nq>eatable. 

Effectiveness  Analyses  -  Effectiveness  analyses  are  used  to:  support 
idendfleation  of  mission  and  performance  objeedves  and  requirements;  support 
allocadon  of  performance  to  functions;  provide  criteria  for  the  selection  of 
alternative  soludons;  provide  analytic  confirmation  that  design  soludons  satisfy 
customer  lequiremenWneeds;  and  support  product  atid  process  verification.  The 
results  of  these  analyses  are  used  in  trade  studies  to  determine  the  best  alternative 
solution  set 

Risk  Management  -  Technical  risk  management  is  an  organized,  analytical 
process  to  identify  what  can  go  wrong  with  a  technical  development  effort,  the 
consequences  if  it  does  go  wrong,  and  a  method  of  either  preventing  or  handling 
the  resulting  problera(s). 

Configuration  Management  -  Configuration  management  is  a  disciplined 
approach  to  applying  teci^cal  and  administrative  direction  and  surveillance  over  the 
life  c^le  of  (^nfiguradon  Items  (Qs)  to:  identify  and  document  the  functional  and 
physical  characteristics  of  CIs;  control  changes  to  CIs  and  their  related 
documentation;  record  and  repon  information  needed  to  manage  CIs  effectively;  and 
audit  CIs  to  verify  conformance  to  specifications,  drawings,  interface  control 
documents,  and  other  contract  requirements. 
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Data  Management  -  Data  management  includes  ensuring  that  a  proper  data  call  is 
accomplish^,  that  only  needed  data  are  asked  for  in  the  contract,  tha;^  data  are 
properly  transmitted,  rweivct^  stored,  and  handled.  It  is  recommended  thtit  data  be 
deliver^  and  stored  in  digital  form  to  be  Computer-Aided  Logistics  Support 
(CALS)  compliant. 

Interface  Management  -  Interface  management  is  essential  to  ensure  that  system 
elements  are  compatible  in  terras  of  form,  fit,  and  function.  Both  internal  and 
external  interfaces  must  be  managed.  Interface  control?  must  be  established  to 
ensure  all  internal  and  external  engineering  interface  requirement  changes  are 
properly  recorded  and  communicated  to  all  affected  OLs. 

Systems  Engineering  Master  Schedule  (SEMS)  -  The  SEMS  is  an  event 
based  scheduling  system  to  plan  all  technical  program  events  (e.g.,  a  design  review 
or  audit)  that  need  to  be  accomplished,  the  significant  activities  that  must  be 
accomplisikcd  to  complete  an  event,  and  the  criteria  by  which  each  activity  within  an 
event  is  judged  to  be  completed. 

Technical  Performance  Measurement  (TPM)  -  TPM  is  the  technical 
performance  measurement  equivalent  to  Cost/Schedule  Control  System  Qriteria 
(C/SCSC)  used  for  cost  and  schedule  progress  measurement  Selected  criticad 
technical  parameters  are  tracked  to  ensure  that  key  performance  requirements  are 
progressing  in  development  over  time  as  planned  Tliis  is  a  management  by 
exception  p^oimance  based  progress  measurement 

Tudinical  Reviews  •  A  technical  review  is  conducted  between  (and  often  during) 
each  level  of  development  to  determine  the  maturity  of  the  development  effort,  the 
amount  of  risk  inherent  in  a  continued  effort,  the  affordability  of  the  design 
solution,  and  whether  the  investment  should  be  made  to  continue  development 


3 *2. 7  Outputs  of  the  Process  :  Decision  Data  Bases;  Specifications, 
Baselines  and  a  System  Architecture 

Program  Peculiar  Specifications  (hardware  and  software),  Interface  Control 
Documents,  Technical  Data  Package,  Decisions,  etc.  The  overall  end  product  of  the 
Systems  Engineering  prcxiess  is  the  technical  data  package;  specifications,  drawings, 
materials  lists,  parts  Usts  as  applicable  for  all  product  and  support  hardware  and  software, 
and  processes^lanning  for  manufacturing  and  support  This  product  matures  through 
successive  applications  of  the  Systems  Engineering  process  during  each  level  of 
development 
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4-0  SYSTEMS  ENGINEERING  THROUGHOUT  THE  LIFE 
CYCLE 

The  Government  acquisition  process  for  major  defense  systems,  as  defined  in 
DOI JD  5000. 1  and  DODI  5000.2  consists  of  five  major  milestone  decision  points  and  five 
major  acquisition,  phases  as  illustrated  in  Figure  4-0.  The  purpose  and  responsibilities  for 
each  phase  are  also  identifiol  in  the  figure.  Tihie  acqui.sition  life  cycle  is  provided  as  a  basis 
for  the  comprehensive  management  and  progressive  decision  making  required  to 
successfully  develop  a  modem  weapon  system,  llie  Major  Technical  Reviews  and  Audits 
shown  m  figure  are  not  completely  consistent  with  MIL-STD-1521B,  Technical 
Reviews  and  Audits  for  Systems,  Equipment  and  Software.;  rather  they  refer  to  the 
Reviews  and  Audits  that  are  consistent  with  MIL-STD-499B(5/d/92  Draft)  as  included  in 
APPENDIX  C.  Witli  formal  approval  of  ivUL-STD-499B,  this  new  set  of  reviews  and 
audits  will  be  adopted  and  MIL-STD-1521B  will  be  superseded. 

Systems  developments  generally  go  through  the  following  phases  as  defined  in  the 
DoD  acquisition  life  cycle: 

The  Conct^t  Exploration  &  Definition  (CED)  phase  is  generally  conducted  by  a 
small  group  oiganized  to  form  a  program  t^ce  within  ^e  contracting  agency.  This  group 
may  draw  on  outside  contractor  or  consultant  support  to  provide  expertise  in  areas  where  it 
is  lacking.  It  evaluates  broad  concepts  that  may  he  capable  of  sad^ying  the  mission  need. 
It  attempts  to  quantify  user  requirements  and  assess  the  capability  of  technology  to  meet  die 
conceptual  requirements.  If  current  technology  is  not  adequately  developed,  contracts  may 
be  awarded  to  bring  hardware  and  software  from  the  labctfatory  stage  to  an  operadond 
state. 


The  Demonsuadon  and  Validadon  (Dem  &  Val)  Phase  involves  several  contractors 
in  compeddon.  The  effort  in  tliis  phase  is  to  establish  a  finn  set  of  system  performance 
specificadons  and  to  allocate  them  to  lower  levels  in  order  to  begin  to  detail  design  features. 
Concurrently,  a  design  is  defined  in  enough  detail  that  its  perfoimance  can  be  analyzed  to 
establish  its  capability  to  meet  system  level  requirements.  Trade  studies  are  conducted  to 
achieve  balance  in  the  design  in  regard  to  cost,  performance,  schedule  and  operadonal 
support  goals.  During  this  phase,  requirements  are  allocated  firt^  the  system  level  down  to 
htudware  and  software  elements. 

The  Engineering  and  Manufacturing  Development  (EMD)  phase  is  usually 
performed  by  a  single  prime  contractor,  although  several  contractors  may  be  selected  to 
build  prototypes  and  to  engage  in  a  demonstradon  before  selecdon  is  made.  During  EMD, 
the  system  moves  into  the  detailed  design  state,  foUowed  by  fabricadon,  assembly  and 
"fu^t  article"  testing.  Several  major  reviews  are  held  during  this  phase.  A  Preliminary 
Design  Review  (PDR)  and  a  Cridcal  Design  Review  (CDR)  are  held  to  examine  how  well 
the  design  meets  requirements  based  on  simulation  and  analysis.  Following  the  testing 
perioch  a  formal  qualification  review  is  held  to  cadfy  that  the  system  has  demonstrated  a 
capability  to  meet  operational  requirements.  The  detailed  software  r^uiiements 
specifications  are  developed  and  completed  Ixfore  PDR.  The  software  design  is  completed 
before  CDR  and  then  proceeds  into  coding  and  checkout. 
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Figure  4-0  Iterative  life-cycle  application  of  the  Systems  Engineering  Process 
(Source:  MIL-STT)-499B) 


This  description  may  take  the  form  of  a  set  of  draft  system  specifications  and 
corresponding  sketches  that  arc  documented  in  an  operational  concept  document  and 
decision  data  base.  The  first  level  of  development  also  determines  the  physical  type  of 
system  to  be  developed  (e.g..  a  tank,  an  airplane,  a  ship,  a  missile,  a  satellite,  a  cucuit 
board,  a  radio,  etc.)  to  satisfy  the  mission  nee^  statement  or  modification  need  statement 

The  second  level  of  development  determines  the  specific  extmmal  characteristics  and 
interfaces,  and  functional  and  performance  requirements  for  the  total  system  (considering 
all  eight  primary  functions  -  development,  manufacturing,  verification,  deployment, 
operations,  support,  training,  and  disposal).  This  description  is  a  more  ^tailed  set  of 
sketches  arid  systems  specifications  for  the  hardware,  software,  persKinnel,  data,  materials, 
services,  facilities  and  techniques  that  make  up  the  physical  architecture  of  the  system. 
This  system-level  set  of  descriptions  is  called  the  functional  baseline  and  includes  the 
system  specification  (Type  A  Specification).  Another  oumut  of  this  second  level  of 
development  effon  is  the  draft  functional  architecture  and  physical  architecture  that 
describes  the  next  level  below  the  system.  These  architectures  make  up  a  draft  functional 
and  performance  requirements  description  (Draft  Type  B  Specifications)  of  the  major 
subsystem  and/or  confi<'uration  items  that  will  make  up  the  system.  It  is  these 
descriptions,  along  witl.  the  system  description,  that  the  government  uses  to  define 
development  contracts. 


The  third  level  of  development  effon  results  in  a  more  detailed  set  of  fur^onal  and 
performance  requirements,  with  both  internal  and  external  interface  descriptions  and 
constraint  descriptions,  for  the  subsystems/configuraiion  items  below  the  system  level. 
This  functional  architecture  is  then  translated  into  a  physical  architecture  (hardware, 
software,  etc.)  providing  physical  solutions  to  the  functional  architecture  requirements. 
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Successive  applications  of  the  Systems  Engineering  process  are  made  to  each 
subsystera/configuration  item  to  develop  the  functional  and  physic^  architectures  of  the 
components,  elements  and  parts  of  the  subsystem/conEguration  item  to  arrive  at  the 
development  baseline  (including  the  Type  B  Specifications)  and  the  product  baseline 
(including  tlte  Type  C  and,  if  lequesicd,  D  and  £  Specifications). 

Fa'  each  level  of  development  the  realization  of  a  complete  functional  and  physical 
architecti  re  is  dependent  on  the  technical  inputs  of  a  variety  of  engineering  specialties,  as 
well  as  by  the  business  requirements  from  contracts,  funds  management,  budget, 
personnel,  and  marketing.  These  specialists  help  define  r^uirements,  and  apply 
knowledge  firom  their  specific  discipline  into  the  development/desi^  efforts. 

To  ensure  that  conflicting  requirements  and/or  interests  from  these  technical  and 
business  specialties  are  resolved  efficiently  and  effectively,  so  that  the  architectures  are 
integrated  and  include  all  needed  down-stream  life  cycle  requirements,  an  integrated  multi¬ 
disciplinary  effort  is  needed.  The  integration  approach  currentiy  used  by  competitive 
industries  and  some  government  program  offices  is  that  of  integrated  product  teams  or 
multi-disciplinary  teams.  These  teams  are  composed  of  the  appropnate  permanently 
assigned  specialists  needed  for  the  level  of  the  development  effort.  Team  members  are 
added  and/or  teams  are  added  as  the  architecture  levels  increase  and  more  detailed 
development/design  results  are  required. 
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5-0  PLANNING  FOR  SYSTEMS  ENGINEERING 


Successful  implementation  of  any  development  program  requires  early  and 
comprehensive  planning.  Planning  for  systems  engineering  commences  at  the  inception  of 
the  program.  Planning  be^ns  with  the  definition  of  program  requirements.  The  various 
System  Engineering  functions  and  tasks  are  identified  and  a  detailed  work  breakdown 
structure  is  prepared. 


5-1  Management  Plans 

Systems  Engineering  Planning  is  documented  in  the  Systems  Engineering 
Maitagement  Plan  (SEMP).  Individual  SEMPs  are  utilized  by  both  the  government  and  the 
contractor  to  govern  the  Systems  Engineering  aedvities  of  each. 


5-1.1  Systems  Engineering  Management  Plan;  Background 

The  Systems  Engineering  Management  Plan  (SEMP)  is  the  tool  used  to  document 
the  technical  processes  of  the  development  program  in  order  to  ensure  well 
coordinated  system  development.  The  SEMP  outlines  what  steps  are  planned  to 
accomplish  the  Systems  Engineering  effort.  MIL-STD-499B  reconunends  that  a 
SEMP  be  prepared  and  followed  by  both  the  Government  (customer)  and  by  the 
contractor. 

5-1.2  Government  SEMP 

The  government  SEMP  is  a  planning  document  that  outlines  the  Systems 
Engineering  activities/tasks  that  must  be  carried  out  by  either  the  government  or 
contractors  throughout  the  life-cycle  of  the  program.  It  is  an  essential  part  of  the 
Program  Management  Plan.  The  government  systems  engineer  writes  the  SBMUP, 
tailoring  it  to  the  specific  system  and  organizational  environment 

The  goverriment  SEMP  provides  the  engineering  community  and  the  program 
manager  with  an  overview  of  the  key  Systems  Engineering  Process  taak.<i  required 
to  be  executed.  It  also  describes  the  technical  organizational  stmeture  to  enable 
development  tasks  to  be  accomplished  by  a  muld-disciplinary  effort  (e.g., 
intej^ted  product  teams).  In  addition,  this  plan  provides  plans  and  criteria  for 
transitioning  critical  product  and  process  technologies  into  the  devdopment  effort  at 
the  iqipropriate  time,  or  for  the  evolutionary  development  or  pre-planned  product 
in^rovement  of  technologies  by  IR&D  or  government  laboratories  in  paurallel  to  the 
system  development  effort  by  the  program  office.  Another  sectitm  of  the  SEMS* 
describes  the  key  trade  studies,  system  effectiveness  analyses,  and  other  system 
analyses  and  controls  planned  (e.g.,  Risk  Management,  Configuration 
Management,  Data  Management,  Interface  Management,  SEMS,  TPM,  and 
Technical  Reviews).  Engineering  specialty  plans  (e.g.,  configuration  management, 
ILSP,  TBMP*  manufacturing  management,  and  other  specialties  such  as  reliability, 
maintaiiutbility,  etc.)  may  be  attached  to  the  SEMP  or  a  short  summary  provkted  to 
demonstnuc4hc  integration  of  the  engineering  specialty  areas. 
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5-1.3  Contractor  SEMP 

The  SEMP  defines  the  contractor's,  or  performing  govemrnent  agency's,  plan  for 
the  conduct  and  management  of  the  hilly  integrate  engineoing  effort  necessaiy  to 
satisfy  the  general  and  detailed  requirements  of  Mil-Std-499  as  implemented  by  the 
Request  for  Proposal  (RFP)  or  contract  schedule,  statement  of  work,  and 
specifications.  The  contractor,  or  performing  government  agency,  uses  the  SEMP 
to:  (1)  document  the  decisions  and  resulting  technical  inqilementadon  necessary  to 
sati^  contract  requirements  and  (2)  communicate  that  approach  both  mtemally  and 
externally.  This  SEMP  will  be  used  by  the  government  program  office  to 
understand  and  evaluate  the  contractor's  proposed  Systems  Enginmtng  work 
during  proposal  evaluation  and/or  as  pan  of  the  contract  monitoring  process.  The 
contractor  systems  engineer  writes  the  SEMP,  tailoring  to  the  specific  system  and 
organizational  environment. 

A  new  SEMP  Data  Item  Description  (DID)  is  provided  with  M1L-STD-499B. 
This  DID  specifies  the  information  that  the  contractor  should  provide  in  each  of  four 
sections  of  the  SEMP.  Section  1  focuses  on  the  planned  Systems  Engineering 
Process  application  for  the  contractual  effort.  Set^on  2  dcs^bes  tte  planned 
approach  transitioning  critical  technologies.  Section  3  describes  the  integration 
of  the  Systems  Engineering  effon  to  include  how  the  multi-disciplinaiy  effort  will 
be  implemented.  Section  4  provides  a  description  of  the  additional  Systems 
Engineering  activities  required  to  coix^lete  1^  contractual  efforts  (e.g.,  engineering 
tools;  systems  integration  plans;  compatibility  with  production,  test  and  support 
activities;  long  lead  items;  and  other  plans  and  controls).  The  purpose  of  the  DID  is 
to  provide  student  information  to  the  contractor  for  preparing  the  SEMP  to  allow 
him  to  tailor  his  Systems  Engineering  approach  to  the  specific  system  acquisition 
for  maximum  effectiveness.  It  is  desired  to  place  the  tailored  SEMP  on  contract, 
not  MIL-STD499B  itself. 


5-2  The  Use  of  System  Effectiveness  Metrics  and  Overall 
System  Cost  Criteria  in  Planning 

The  Relationships  among  key  system  effectiveness  metrics  and  Life-Cycle  Cost 
(LCC)  and  Design  to  Cost  (DTC)  requirements  and  their  relationships  to  operational 
suitat^ty.  effectiveness  and  affordabili^  are  described. 

Four  facets  of  system  effectiveness  are: 

Cost  Effectiveness  -  a  measure  of  affordability  and  life-cycle  cost  as  a  function 
of  design-to-cost,  suitability,  dependability,  and  capability. 

Suitability  -  a  measure  of  the  degree  to  which  an  item  is  iq)proi^te  for  its 
intended  use.  (Is  it  the  right  system  for  the  need?)  Includes  comnderation  of 
compatibility,  inter  operability,  transportability,  man-machine  interfaces,  training, 
safe^,  security,  and  documentation. 

Dependability  -  a  measure  of  the  degree  to  which  an  item  is  operable  a^  capable 
of  performing  its  required  function  at  any  (random)  time,  given  its  suitability  for  the 
mission.  (Will  it  be  available  and  operate  when  and  as  long  as  needed?)  Includes 
availability,  reliability,  usage  rates,  durability,  survivability,  penetrability, 
vulnerability,  mobility,  flexibility,  and  repainibility. 
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Capability  -  a  measure  of  the  system  ability  to  achieve  the  mission  objectives, 
given  the  system  is  dependable  and  suitable.  (Will  it  get  the  job  done  when 
engagement  takes  place?)  Includes  accuracy,  payload,  range,  lethality,  ability  to 
destroy,  numbei  of  engagements,  and  information  rates. 

Key  defuiidons  and  relationships  of  these  system  effectiveness  facets  are: 

DT&E  Metrics  -  The  four  above  elements  of  systems  effectiveness  are 
Development  Test  &  Evaluation  (DT&E)  metrics  that  must  be  satisfied  by  the 
system/CIs  during  development.  These  are  the  measures  (DT&E  metrics),  in  the 
form  of  program  peculiar  specifications,  th^it  the  development  testers  (government 
and  contractor)  must  verify  and  the  configuration  management  personnel  must  audit 
to  ensure  ihat  the  product  and  processes  of/from  the  development  effort  do  in  fact 
satisfy.  . 

OT&E  Metrics  -  The  system  provided  by  the  government  developers  to  the  users 
must  be  operationally  effective  and  operadonally  suitable.  These  measures  of 
efteedveness  are  tiam^ted  into  measures  of  performance  called  Operadonal  Test  & 
E^'aluadon  (OT&E)  metrics  during  requirements  analysis  (an  element  of  the 
Systems  Engineering  Process)  to  provide  performance  requirements  for  the 
funedons  that  must  be  accomplished  by  the  system.  The  operational  test 
community  performs  independent  testing  to  ensure  tluit  the  system  delivered  does  in 
fact  meet  die  OT&E  metrics. 

Affordability  •  Characteristics  of  the  product  with  a  price  approaching  its 
functional  worth  and  within  the  limits  of  what  the  government  is  able  and  willing  to 
payAnvest. 

Design  to  Cost  (D  TC)  -  A  method  of  evaluating  cost  and  technical  performance 
so  that  they  are  relatively  equal.  The  essence  of  the  DTC  effort  is  making  the 
design  converge  on  cost  instead  of  letting  design  deteranne  tlie  cost 

Life*CycSe  Cost  >  Ti  c  total  cost  of  acquiring  and  utilizing  a  system  over  its  entire 
life  span.  The  LCC  includes  aU  RDT^.,  p^uction,  operations  and  support,  and 
disposal  costs.  It  is  the  role  of  Systems  Engineering  to  minimize  this  for 
affordability  while  meeting  operational  suir, ability  and  effectiveness  requirements. 
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6-0  SYSTEMS  ENGINEERING  OUTPUTS 


6-1  SE  Baselines  Used  in  Acquisition  Management 

The  technical  baselines  (functional,  allocated  and  prod^t)  that  identify  and  define 
an  item's  functional  and  physical  chanictcristics  are  used  in  Systetm  Engineering  to 
document  the  outputs  of  the  Systems  Engineerinj^  process.  These  baselines  are  refen^  to 
as  conhguration  baselines  and  art;  guided  by  MIL-STD-973,  Configuration  Management 

Three  other  basdines  that  are  managed  by  the  program  manager  are  called  program 
baselines.  These  baselines  (concept,  devehp.MAt,  and  production)  embody  the  cost, 
schedule  and  peiformance  objectives  of  the  program.  These  baselines  are  required  on  all 
programs  for  measuring  and  reporting  status  of  nrogs'i'  ’n  implementation  and  guided  by 
DODI  5000.2,  Part  1 1 A  and  DOD  5000.2M.  Pan  14. 


6-2  Specifications;  General  and  Program  Peculiar 

The  initial  definition  of  system  requirements  is  ^jected  throu^  a  combination  of 
formal  speciHcadons  and  planning  documentation.  Specifications  rasically  cover  the 
technical  requirements  for  system  design. 

A  specification  is  a  document  prepared  specifically  to  suftport  acquisition  which 
clearly  and  accurately  (hopefully)  describes  essential  technical  requirements  for  purchasing 
materiel.  Procedures  necessary  to  detennine  that  the  requirements  for  the  matenel  covered 
by  the  specification  have  been  ntet  are  also  included  as  specifications  (Source  MIL-STD* 
961C  -  Military  Specifications  and  Associated  Documents,  Preparation  of).  There  is  no 
definition  for  a  specification  given  in  MIL-STD-490A  or  B  (draft)  -  Program-Uttique 
Specifications,  Preparation  of  MIL-S'ID*973,  Configuration  Management,  references 
MIL'S1I}-961  for  tiie  definition. 

MlL-S’ID-490  is  closely  related  to  MIL-STD-961  in  that  the]^  both  addreis  the 
preparation  of  specifications  used  by  DoD.  However,  there  are  significant  differences 
between  the  types  of  specifications  prepared  under  each  standard  and  they  serve  different 
puiposes.  Spe^cations  prepared  under  MIL-S'n>490  are  program-unique  docun^ts 
necessary  to  control  item  configuration  and  establish  baselines.  Program-unique 
specifications  are  unique  to  a  particular  weapon  system  or  program,  and  little  or  no 
potential  exists  for  the  application  of  these  documents  to  other  systems  or  programs. 
Furthermore,  program-unique  system,  development,  product,  material  and  process  type 
specifications  are  used  when  it  is  the  (Sovemment's  intent  to  control,  procure,  and  support 
the  exact  design  of  the  item;  or  if  the  specifications  are  intended  to  control  the  process  or 
material  during  development  phases. 

In  contrast,  specifications  prepared  under  MIL-STD-96i  have  or  could  have 
multiple  applications  and  are  needed  to  support  the  goals  of  the  Defense  Standardization 
Program  to  limit  the  variety  of  equipnxsnt  and  supplies  in  military  supply  systems  [ref: 
DOD4n0.3-M]. 
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6-3  Specifications  used  in  Systems  Engineering 

In  dealing  with  large  systems,  there  are  numerous  elements  that  must  be  covered  by 
specification  (dictating  technical  requirements)  and  by  planning  documentation  (providing 
the  "HOW",  "WHEN",  and  "WHERE"  information  pertaining  to  program  implementation 
and  control).  Some  components  of  the  system  may  require  an  extensive  amount  of 
research  and  development  effort,  while  other  components  are  obtained  directly  from 
existing  supplier  inventories.  Depending  on  the  degree  of  development  required,  and  the 
uniqueness  of  any  processes  applied  to  development,  there  may  be  a  large  variety  of 
specifications  necessary  to  provide  the  guidance  and  controls  necessary  for  the 
development  of  the  system  and  its  components. 

Both  types  of  specifications  are  needed  for  the  SE  effort.  For  product 
developments,  system  level  specifications  under  MIL-STD-490  are  needed  to  baseline 
system  functional  performance.  I’hc  systems  specification  is  normally  developed  during 
the  DEN^VVAL  phase  prior  to  EMD.  Development  specifications  are  prepared  for  individu^ 
configuration  items  (Cl)  during  EMD  in  accordance  with  MIL*STD-490.  Then  for  each  Cl 
a  product  specificadon  is  developed  along  with  needed  material  and  process  spedficadons 
under  MIL-STD-490.  In  addition,  military  General  SpeciEcadons  that  have  been 
developed  under  MIL-STD-961  and  tested  in  the  Acquisition  Management  Systems  and 
Data  Requirements  Control  List  (AMSDL)  are  also  used  'o  guide  product  developments  and 
manufacturing  requirements. 

like  other  aspects  of  Systems  Engineering  there  is  a  hierarchy  to  the  spedficadons 
which  begins  with  top  level  systems  specifications  and  tends  to  flow  dovkii  to  those  at  a 
lower  level  which  address  details  of  fabrication  and  process. 

Figure  6-3a  presents  a  hierarchy  of  technical  specifications  showing  where  each 
type  resides  in  an  overall  set  of  specifications.  The  figiurc  also  gives  some  indication  as  to 
how  the  level  of  detail  increases  as  you  move  from  top  level  (type  "A"  to  lower  level 
specifications.  The  classification  and  description  of  specifications  are  the  following: 

(1)  System  Specificadon  (Type  "A")  Includes  the  technical,  performance, 
operation  and  support  characteristics  for  the  system  as  an  entity.  It  includes  the 
allocaticn  of  requirements  to  functional  areas,  and  it  defines  the  various  functional 
area  interfaces.  Information  derived  from  the  feasibility  analysis,  operational 
requirements,  maintenance  concepi,  and  the  functional  analysis  is  covered  by  Type 
"A". 

(2)  Development  Specification  (Type  "B")  This  type  includes  the  technical 
requirements  for  any  item  below  the  system  level  where  research,  design,  and 
development  are  accomplished.  This  may  cever  an  equipment  item,  assembly, 
computer  program,  facility,  critical  item  of  support,  and  other  like  items.  Each 
specification  must  include  the  performance,  effectiveness,  and  support 
characteristics  that  are  required  in  the  evolving  of  design  from  the  system  level  and 
down. 

(3)  Product  Specification  (Type  "C")  Included  are  the  technical  requirements  for 
any  item  below  the  top  system  level  that  is  currently  in  the  inventory  and  can  be 
procured  "off  the  shelf.  This  may  cover  standard  system  components  (equipment, 
assemblies,  cables,  etc.),  or  a  specific  computer  program,  a  spare  part,  a  tool,  and 
like  classes  of  components. 
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(4)  I^x>cess  Specification  (Type  "D")  This  type  of  speciHcation  includes  the 
technical  requirements  that  cover  a  service  that  is  performed  in  the 
prepamtion/fabrication  of  any  component  of  the  system.  Examples  may  include 
machining,  bending,  welding,  plating,  forming,  heat  treating,  toaiidng,  packing 
and  any  other  necessary  process  that  requires  definition. 

(5)  Material  Specification  (Type  "E")  This  specification  type  describes  the 
technical  requirements  that  apply  to  raw  materials,  mixtures  (e.g.,  paints,  chcimcal 
compounds,  etc.),  and/or  semi-fabricated  materials  (e.g.,  electrical  cable,  piping, 
etc.),  that  me  used  in  the  fabrication  of  a  product  used  in  the  system. 


Figure  6-3a  Hierarchy  of  technical  specifications 

(hom,  B.S.  Blanchard,  System  Engineering  Management,  with  pennission) 
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Example  spcciEcations  used  in  Systems  Engineoing  include  the  following: 

Draft  System  Specification  -  Output  of  Concept  I^vel  of  Development 
(Concept  Exploration  &  D^nition  Phase) 

System  Specification  -  Output  of  System  Level  of  Development 
(Demonstrcuion  &  Validation  Phase) 

Draft  Development  Specifications  -  Output  of  System  Level  of  Development 
(Demonstration  &  Validation  Phase) 

Development  Specifications  •  Output  of  the  Engineering  &  Manufacturing 
Development  (EMD)  Phase,  as  early  as  preliminary  designs  or  as  late  as  tlw 
Functional  Configuration  Audit  (FCA) 

Draft  Product  Specifications  (Material  &  Process)  -  Output  of  EMD  Phase 

Product  Specifications  (Materials  &  Process)  -  Output  of  Initial  Production 
Lot 

Preparation  of  specificadons  is  an  important  engineering  activity.  The  system 
specification  is  prepaid  at  program  inception  during  the  conceptual  design  phase. 
Development  and  p^uct  si^ifications  are  often  based  on  the  results  of  trade  studies, 
"make-or-buy"  decisions  and  the  like.  They  are  generally  prepared  during  the  preliminaiy 
desig^  phase.  Process  and  material  specifications  are  primarily  orient!^  to  production 
activities  and  are  normally  prepared  during  the  full  scale  design  development  phase. 
Specifications  are  documents  utilized  primarily  for  acquiring  items,  including  the 
procurement  of  off-the*shelf  components,  contracting  for  the  design  and  development  of  a 
new  item,  testing  and  verification  of  a  product,  and  the  like.  Specifications  may  be  i^lied 
on  contacts  and  imposed  on  major  contracts,  subcontractors  and  suppliers  for  goods  and 
services.  Specifications  are  of  necessity  requirements  oriented  and  must  be  written  in  a 
clear  and  concise  manner.  Vague,  redundant,  nebulous,  and  ambiguous  language  should 
be  eliminated.  Requirements  should  be  quantifiable  and  verifiable,  and  shou^  not  require 
judgment  in  interpretation.  Phrases  such  as  "best  design  practices"  or  "good 
workmanship"  should  be  avoided.  In  applying  specifications,  care  must  be  exercis^  to 
ensure  that  they  are  prepared  to  the  proper  depth  of  detail  and  ^iplied  at  the  appropriate 
level  in  the  system  hierarchy.  Such  documents  must  be  detailed  to  the  extent  i^ui^  to 
establish  the  basis  for  appropriate  design  and  the  application  of  suitable  matemls  and 
processes.  For  complex  specifications,  test  practice  is  to  extend  the  concept  of  document 
mspections  first  applied  in  software  development  to  a  review  of  requirements  documents. 
A  document  insp^on  team  consisting  of  a  trained  experience  moderator  Geader)  together 
with  a  team  of  reviewers  (multi-disciplined  as  required)  and  the  documents  auAor  is 
convened  to  verify  and  validate  the  requirements  included  in  the  specification  document 
Through  a  disciplbcd,  structured  approach  the  document  is  reviewed  to  determine  whether 
the  requirements  are  complete,  are  necessary  and  cleaiiy  and  unambigixiusly  presented. 

Figure  6-3b^rovides  a  sample  specification  tree  (simplified)  for  a  typical  system 
showing  the  relationship  of  each  of  the  specification  types  within  a  typical  system  family 
tree. 
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Figure  6-3b  Sample  Specification /Documentadetn  Tree 

(from,  B.S.  Blanchard,  System  Engineering  Management,  with  penniasioa) 

The  figure  shows  the  hierarchy  of  a  documentation  tree.  The  tree  is  developed  fitxn 
the  top  down  st^ng  with  the  preparation  of  the  top  level  system  specification. 
Subsequratly  additional  specifications  are  added,  with  additional  detail  added  at  each  level. 
The  tree  is  a  combination  of  specifications  and  reference  standards. 

The  critical  task  is  in  the  efficient  tailoring  of  the  specifications  developed  to  the 
particular  system  to  which  they  are  iqiplied.  Even  though  di^gn  needs  may  dictate  the  use 
of  an  off  the  shelf  component,  spe^c  requirements  of  the  implication  may  be  quite 
^ferent  from  those  in  which  the  component  has  been  previously  applioi.  In  some 
instances  the  appUcation  may  dictate  a  re>engineering  or  "mUitarizatiofi"  of  the  commercial 
component  to  satisfy  needs  of  the  specific  application.  A  balance  must  be  struck  between 
"ovCT  spi^fication”  (a  complaint  of  many  contractors  who  participated)  and  "under 
spotification"  resulting  in  designs  that  do  not  meet  operation  needs. 
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7-0  REQUIREMENTS  ANALYSIS 


7-1  The  Requirements  Analysis  Process 

Requiieinents  analysis  helps  both  the  govemment  program  office  and  the  contraaor 
in  problem  definition.  Requirements  are  essentially  a  statement  of  the  problem  to  be  solved 
by  the  development  agencies.  Il  is  essendal  that  all  involved  organizations  understand  what 
the  system  is  suppose  to  do,  where  the  products  of  the  system  will  be  used,  under  what 
conditions  the  piquets  will  be  used,  and  who  will  use  the  products  of  the  system.  The 
results  of  this  analysis  provides  developers  with  an  understanding  of  WHY  the  system  is 
needed.  From  this  understanding  the  pro^m-unique  specifications  (the  WHAT)  arc 
produced  by  developers  that  explain  to  designers  the  product  and  process  characteristics 
required  to  be  satisfied  by  the  design  (the  HOW). 


7-2  Inputs  to  and  outputs  of  the  Requirements  Analysis  portion 
of  the  Systems  Engineering  process. 

Three  essential  outputs  are  produced  by  the  requirements  analysis. 

( 1 )  An  operational  description  that  explains  the  operational  need;  system  missions; 

operational  sequences;  operation^  environments;  conditions  and/or  events  to 
which  the  system  must  respond;  constraints  on  the  system;  user  roles; 
organizations  that  will  operate,  support  and  maintain  the  system;  and 
operational  interfaces  with  other  systems.  _ 

(2)  A  functional  description  that  documents  in  a  decision  t^ta  base  the  task.s  that 
must  performed  by  the  system;  the  qualitative,  quantitative  and  timeliness 
peiformance  requirements/constraints  of  the  system  ;  interface  requirements; 
and  veriheation  requirements. 

(3)  A  physical  description,  also  documented  in  a  decision  data  base,  tliat  provides 
physical  interface  data  und  characteristics  of  information  displays  and  operator 
controls;  relationships  of  operators  to  system  equipment;  characteristics  of  the 
users  such  as  special  operational  environments  and  movement  or  visual 
limitations;  and  system  p^omiance  characterisnes  such  as  physical  capacity, 
power,  size  or  weight  li^tations,  technology  limitations  or  Gfe,  NDI,  COTC 
or  reusability  requirements. 

There  are  three  types  of  inputs  to  the  requirements  analysis  used  to  produce  the 
necessary  outputs. 

(1)  Those  inputs  that  are  converted  through  the  analysis  process  into  the  desired 
outputs  (mission  needs  statement  (MNS),  operational  requirements  documerit 
(ORD),  measures  of  effectiveness  (MOEs),  and  program-unique/pcculiar 
specifications  developed  during  the  prior  development  effort). 

(2)  Those  inputs  that  control  the  requirements  analysis  process  such  as 
organizational  policies  and  procedures,  military  (general)  speciffcaiions  and 
standards,  constraints  (technology,  funds,  schedule,  skills,  etc.),  and 
utilization  environments. 
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(3)  Those  inputs  needed  to  enable  the  requirements  analysis  to  be  efi^^eetive  such  ar. 
multi-dis^-iplinary  product  team  efforts,  an  effective  decisioii  data  base  that 
tracks  prior  efforts,  changes  and  decisions,  and  tools,  usually  computer  based, 
diut  m^e  the  analyses  more  eiBcient. 

7-3,  The  Role  of  Trade  Studies  in  the  Development  of 
Functional  and  Performance  Requirements. 

Trade  studies  are  required  because  requirements  from  different  customers 
(developers,  manufacturers,  verifiers,  deployers,  operators,  supporters,  trainers,  and  those 
responsible  for  disposal)  often  conflict,  imposed  constraints  Uinit  options  and  resources  are 
not  unlimited.  Trade  studies  are  used  for  the  following  reasons: 

(1)  To  resolve  conflicts  among  mission  objectives,  input  constraints,  human  factor 
considerations  and  utilization  environments; 

(2)  Tc  ensure  that  a  cost  effective  balance  of  functional  and  performance 
requirements  are  developed;  and 

(3)  To  reduce  technical  risks  so  that  there  is  a  higher  probability  that  all  customer 
problems  will  be  solved. 

The  role  of  trade  studies  therefore  ranges  from  helping  to  identify  the  proper  set  of 
system  requirements,  supporting  the  control  function  to  asstire  that  a  balance  is  achieved 
among  the  various  functional  ne^s  €<f  thv  system,  and  as  a  risk  assessment  tool  to  establish 
the  maturity  of  candidate  technologies  and  to  compare  the  efficacy  of  alternate  ^stem 
concepts.  The  emphasis  areas  for  t:^e  studies  change  throughout  the  variou:::  acquisition 
phases  as  described  below: 

Concept  Exploration  and  Definition  •  During  this  phase  ,ttade  studies  focus  on 
comparing  various  technologies  and  approaches.  Various  cortceptsfor  meeting 
mission  needs  are  compared  and  traded  off  during  this  phase.  Trade  studies  are 
used  to  select  alternate  sysum  cot^gurations  to  explore  in  later  phases. 

Dcmonstratio’iy'Validation  <  Trade  svAdies  are  used  during  this  phase  to  select 
preferred  techrwlogies  and  to  reduce  systtm  alternatives  to  a  testable  number. 

Engineering  and  Manufacturing  Development  -  The  trade  stud"  emphasis  during 
this  phase  is  directsa  to  selecting  among  componenstpart  designs,  selecting  among 
testing  methods  and  selecting  suitable  support  processes. 

Production  and  Deployment  •  Trade  study  activity  is  directed  unvard  cor.tparing  the 
advantages  of  proposed  design  changes,  evaluating  new  mission  requirements  and 
assess  the  merits  of  incorporating  new  technologies. 


7-4  The  Importance  of  Requirements  Analysis  to  Systesns 

Engineering. 

Requirements  Analysis  is  critical  Many  programs  arc  doomed  to  failure  largely 
because  the  requirements  are  not  fully  or  correctly  rcEned.  The  most  efficient  system 
development  process  is  of  little  importance  if  you  build  the  wrong  system. 

Application  of  the  Systems  Engineering  process  to  milita^  avionics  is  complex  in 
application  because  of  the  complexity  of  high  p^orroance  avionics  systems.  The  process 
is  olion  unduly  compromised  when  avionics  system  development  is  cona mined  by  other 
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de'iign  choices  imposed  on  the  aircraft  as  a  total  weapon  system.  As  a  Mission  Needs 
Statement  is  first  translated  into  an  aircraft  design,  avionics  is  only  a  secondary 
consideration.  The  aircraft  structvu'c,  aerodynamic  properties,  engines  and  control  systems 
are  usually  tlie  first  design  elements  considered  in  the  development  of  the  aircraft  as  a 
weapon  system.  Often  the  avionics  Systems  Engineering  team  is  not  part  of  the  decision 
process  at  this  level,  resulting  in  ;  ometimes  unnecessarily  limiting  the  avionics  systems 
choices  to  costly,  stringently  complex  designs.  For  the  most  efficient,  cost  effective 
process,  the  avionics  Systems  Engineering  team  (especially  the  avionics  architect)  must 
participate  in  the  early  definition  process  where  high  level  aircraft  systems  choices  axe 
made. 


In  detailing  (specifying)  die  avionics  it  is  important  to  start  with  a  "clean  sheet  of 
"paper"  when  possible.  Too  often,  the  preliminary  avionics  specification  is  derived  fiom 
the  most  recent  aircraft  of  a  sinrilar  type.  Wc  then  attempt  to  "stretch"  the  specification  by 
Increasing  the  peifomiance  specified  in  certain  areas  where  wc  feel  the  technology  has 
matured  to  allow  a  performance  increase  without  undue  risk.  In  contrast,  the  "clean  sheet" 
of  paper  concept  allows  the  design  fo  be  focused  on  the  newly  specified  avionics  needs  for 
the  weapon  system  rather  than  to  carry  over  specifications  from  the  predecessor  aircraft  that 
may  no  longer  be  necessary.  This  approach  can  help  to  avoid  overly  complex  avionics, 
often  characteristic  of  the  conventional  specification  method.  Reviewing  the  specification 
of  me  predecessor  sircratt  is  useful,  but  each  requirement  retained  should  be  thoroughly 
validate  before  it  is  retained  for  the  new  aircraft  development.  Because  of  the  significance 
of  requircmeauii  crjilysls  the  term  "Requirement?  Engineering"  has  been  coined  and  used  to 
describe  this  aspect  of  engineering.  Specific  computer  aided  tools  have  also  been 
developed  specifically  to  suppent  the  sever^  aspects  of  Requirements  Analysis. 
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8-0  FUNCTIONAL  ANALYSIS,  SYNTHESIS  AND  WORK 
BREAKDOWN  STRUCTURES 


8-1  Evolution  of  the  Functional  Architecture  to  a  Physical 
Architecture 

Functional  Analysis  consists  of  decomposing  the  higher  level  functions  that  came 
out  of  requirements  analysis  into  lower  level  functions.  Tne  operational,  perfonnance  and 
otlMsr  requirements  are  then  allocated  to  these  fiincdons  at  the  appropriate  level.  Interfaces 
are  definal  and  from  this  process  a  functional  architecture  of  the  system  is  developed.  It  is 
important  to  emphasize  that  the  process  includes  a  looping  back  up  to  the  requirements 
aiudysis  activity  to  constantly  evaluate  whether  or  not  the  requirements  are  met  as  the 
functional  aiehitectuie  evolves. 


8-2  _  The  Evolution  and  Uses  of  the  Engineering  WBS 

As  each  level  of  the  system's  architecture  evolves,  a  product  and  process  oriented 
Work  Breakdown  Structure  (WBS)  can  be  developed.  There  is  a  product  element  of  the 
WBS  assigned  for  each  product  specification  derived  for  a  physical  architecture.  An  the 
levels  of  physical  architecture  increase,  so  do  the  levels  of  the  WBS.  This  type  of  WBS 
can  be  to  as  the  engineering  part  of  the  program  m  contract  WBS  because  it  depicts 

the  product  structure  for  which  engineering  efforts  must  be  applied  to  satisfy  customer 
requirements. 

The  engineering  WBS  can  also  be  effectively  used  as  an  organizational  model  to 
organize  the  development  and  to  assign  integrated  product  or  multi-disciplinary  teams. 
This  approach,  for  example,  is  used  in  sevei^  Air  Force  aircraft  and  missile  programs. 
Each  team  is  given  one  product  of  the  WBS,  die  resources  needed  for  its  development,  and 
is  held  responsible  for  its  development  The  teanri  is  given: 

(1)  The  responribility  to  meet  allocated  requirements  (including  integration  with 
interfacing  products). 

(2)  The  authority  to  accomplish  the  tasks  needed,  and 

(3)  The  accountability  for  the  funds  associati^d  with  tiiat  development  effort 

Appropriate  specialists  from  the  product  teams  aie  assigned  to  the  process/functional 
elements  of  the  WBS  related  to  the  prime  item  equipment  of  which  their  product  team  is  a 
part  For  an  example,  the  support  specialists  from  each  lower-level  product  team  working 
to  support  a  radar  (prime  item  equipment)  development  would  be  assigned  to  a  support 
functional^process  team  to  ensure  that  the  system  elements  (hardware,  software,  personnel, 
etc.)  need^  to  support  the  radar  are  developed  along  with  the  r^ar  products.  This 
iq)proach  ensures  that  specialized  support  needs  of  all  r^ar  product  elements  can  be  fuUy 
supported.  Likewise,  the  engineering  WBS  can  be  used  to  as.sign  management  teams.  For 
example,  the  radar  management  team  can  be  composed  of  team  leaders  of  each  of  the 
product  teams  for  the  products  that  make  up  the  radar.  In  like  manner,  if  the  radar  is  the 
prime  item  equipment  in  a  fire  control  subsystem,  the  fire  control  subsystem  team  can  be 
made  up  '  team  leaders  of  each  of  the  functional/process  teaim  and  the  radar  team.  This 
"team  of  teams"  approach  helps  to  ensure  the  integration  of  all  products  that  make  up  a 
subsystem  by  having  team  members  that  are  responsible  for  the  success  of  their  individual 
products  and  the  subsystem.  As  with  the  product  teams,  appropriate  business  specialists 
need  to  be  assigned  to  appropriate  teams.  Each  team  (subsystem,  prime  equipment  and 
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functional)  may,  also  have  an  assigned  leader,  staff  and  specialty  engineers  assigned  to 
ensure  the  integrated  development  of  their  related  product  and  process  system  elements. 
The  IPT  approach  supports  the  use  of  incremental  technical  reviews  and  audits.  Much  of 
the  review  activity  at  the  lower  level  WBS  elements  is  accomplished  through  team  reviews 
and  regular  meetings.  Major  reviews  can  be  managed  by  having  a  series  of  incremental 
reviews  at  subsystem  and  functional  levels.  As  reviews  at  the  lowest  reviewable  level  are 
completed,  the  incremental  reviews  can  proceed  to  higher  and  higher  levels  in  the 
Engineering  WBS.  When  the  major  reviews  such  as  the  PDR  and  the  CDR  are  conducted, 
they  consist  largely  of  demonstrations  of  compliance  reflecting  the  earlier  reviews  at  lower 
levels.  In  this  manner  it  hoped  to  avoid  the  large  scale  reviews  witnessed  in  major  system 
programs  when  hordes  of  reviewers  descend  upon  a  contractor  to  conduct  simultaneous 
reviews  of  all  key  program  elements  usually  breaking  into  "splinter  groups  of  specialists 
reviewing  each  si^ificant  program  element.  Reviews  of  this  type  are  not  usually  very 
efHcient,  suffer  from  poor  communications  at  a  full  program  level  and  usually  take  a 
considerable  time  period  to  idendfy  and  resolve  the  most  important  issues.  The  incremental 
review  process  promises  to  make  such  reviews  considerably  more  efficient  and  effeedve. 

8-3  Roles  of  the  WBS  in  the  Program  Office 

The  engineering  part  of  the  program  or  contract  WBS  is  an  impemdve  for  getting 
the  engineering  effort  accomplished  efficiendy  and  effeedvely  and  for  assigning  integrated 
product  teams.  It  is  also  useful  for  deriving  statement  of  work  tasks.  A  statement  of  woik 
(SOW)  tells  a  contractor  what  woik  the  contractor  must  accomplish.  The  work  breakdown 
structure  diedona^  for  each  element  of  the  engineering  WBS  provides  a  task  descripdon 
usehil  for  structuring  requirements  for  section  three  of  the  SOW. 

TTie  WBS  also  provides  an  outline  for: 

(1)  Determining  Contract  Line  Item  Numbers  (CLINs)  that  specify  the  deliverables 
of  a  contract, 

(2)  Assessing  and  identifying  technical  risks, 

(3)  Establishing  key  interface  identification  and  control  requirements, 

(4)  Evaluating  and  managing  Engineering  Change  Proposals  (ECPs), 

(5)  Determining  the  number  and  type  of  technical  reviews  and  audits  required. 

In  addition,  when  the  appropriate  program  level  elements  (e.g.,  Data,  Program 
Management,  Site  Activation  and  Spares)  are  added  to  the  engineering  part  of  the  WBS  to 
meet  MIL>STD-881B  requirements,  a  structure  is  provided  for  forming  a  budget  and 
making  cost  estimates.  The  cost  data,  collected  on  the  elements  of  the  work  breakdown 
stmetures  specified  in  MIL*STD*88 IB,  provides  cost  information  for  making  independent 
cost  estimates  (ICE)  and  the  COEA  early  in  the  program.  The  WBS  is  also  used  for 
collecting  and  analyzing  costs  for  Cost  Performance  Reporting  (CPR)  and/or  C/SCSC 
reporting. 

The  WBS,  has  historically  not  been  widely  used  by  the  engineering  community  and 
has  been  primarily  used  by  the  business  side  of  the  program  office  for  cost  and  budget 
purposes.  The  MJ^-STD-881  has  had  this  role  as  its  cent^  focus.  The  proposed  stands^ 
revision,  MIL-SlD-BSlB,  places  equal  emphasis  on  the  engineering  roles  and  cost  roles, 
and  a  WBS  developed  to  support  the  Systems  Engineering  Process  is  expected. 
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9-0  TECHNICAL  RISK  MANAGEMENT 


9-1  DeHning  Risk 

Acquisition  risk  is  a  measure  of  the  potential  inability  to  achieve  program 
objectives,  including  technical  performance,  cost  or  schedule.  The  level  of  risk  has  two 
components:  the  probability  of  failing  to  achieve  a  particular  outcome,  and  the 
consequences  of  failing  to  achieve  that  outcome.  Defense  system  acquisition  programs 
are  often  aimed  at  providing  significant  increases  in  capabUity  over  existing  systems, 
m^ng  ri^  inherent  to  many  aspects  of  the  program. 

The  technical  risks  can  encompass  any  of  the  technical  disciplines/specialties  tliat 
impact  the  ability  to  achieve  any  of  the  eight  primaiy  functions  of  the  system  (development, 
manufacturing,  verification,  deployment,  operations,  support,  services,  training,  & 
disposal).  Requirements  definition,  operating  environment,  material  imperdes,  system 
complexity,  maturity  of  technology,  software,  support,  reliability  &  maintainability,  inter 
opmbility,  and  int^aces  are  among  the  sources  of  technical  risk  to  a  program.  Failure  to 
appropriately  addhess  such  areas  can  have  an  adverse  effect  on  the  performance,  cost,  or 
schedule  objectives  of  the  program. 

In  general,  high  system  complexity  Oi&fdwaie  and/or  Software)  or  technical 
immaturity  tends  towards  increasing  probability  of  failure  to  meet  objectives.  This 
probability  of  failure,  coupled  with  the  ensuing  consequences  (performance,  cost,  or 
schedule),  will  provide  an  indication  of  the  overall  level  of  program  technical  risk. 

( 1 )  Low  risk  is  characterized  by  mature  technology,  demonstrated  capabilities,  and 
few  changes  required  to  develop  system.  Tbere  is  little  potential  to  impact 
cost,  sch^ule,  or  performance  objectives  and  normal  contractor  effort  and 
government  monitoring  generally  will  be  all  that  is  required. 

(2)  Moderate  risk  is  characterized  by  breadboard/brassboard  demonstrations, 
capabilities  not  fully  demonstrated,  and  design  iterations  required  to  achieve 
objectives.  Some  (Usnipdon  of  schedule,  increase  in  cost,  or  degradation  in 
performance  requiring  special  contractor  effort  and  close  government 
monitoring  is  associated  with  moderate  risk  items. 

(3)  High  risk  is  characterized  by  technology  not  having  been  demonstrated, 
capabilities  which  do  not  currently  exist,  and  expectation  that  a  significant 
number  of  design  iterations  will  be  needed  to  meet  performance  requirements. 
High  risk  also  infers  serious  cUsruption  of  schedule,  increase  in  cost,  or 
degradation  in  performance  and  requires  immediate  attention.  Risk 
management  is  part  of  the  systems  analysis  and  control  element  of  the  Systems 
Engineering  process.  Early  risk  identification  and  assessment  allows  one  to 
plan  appropriate  risk  mitigation  measures  into  the  program,  plan  for  tracking 
(e.g.,  technical  performance  measures)  and  reassessment,  and  implement 
corrective  actions. 
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9-2  The  Technical  Risk  Management  Process 

DODI  5000.2,  Part  5B  formalizes  the  requirement  for  a  risk  management  program 
within  each  acquisition  program.  At  each  milestone,  the  program  manager  must  provide  an 
assessment  of  risks  along  with  plans  on  how  each  of  the  identified  risks  will  be  managed. 
To  accomplish  this,  the  program  manager  needs  a  process  which  may  be  applied  within 
each  phase  of  the  development  program.  The  risk  management  process  consists  of 
Planning,  Assessment,  An^ysis,  and  Handling.  Planning  is  needed  to  establish  progi^ 
objectives;  acceptable  risk  levels;  and  identify  risk  management  resources,  responsibilities, 
and  techniques.  As.sessment  includes  identification  of  the  risks  and  their  relative 
importance.  Expert  interviews,  detailed  review  of  program  and  technical  plans  (c.g. 
SEMP,  ILSP,  TEMP),  and  technical  assessments  arc  some  of  the  methods  used  to  assess 
risks.  The  work  bre^down  structure  can  be  a  useful  tool  in  identifying  and  focusing 
attention  on  the  risk  areas. 

Risk  Analysis  is  the  quantification  of  risk  areas  and  assignment  of  priorities.  Risk 
analysis  is  supported  by  various  risk  analysis/simulation  tools.  In  addition,  the  use  of 
experts  in  specific  subject  matters  experts  and  use  of  the  templates  (DOD  4245.7-M)  arc 
effective  ways  to  assess  and  analyze  risk.  Outputs  from  risk  analysis  include  watch  lists 
and  a  list  of  those  parameters  (technical  performance  measurements)  which  should  be 
tracked  during  the  development  program.  Risk  Handling  is  taking  the  appropriate  actions 
to  mitigate  ri^.  These  actions  geneimly  fall  into  one  of  five  categories:  Avoidance,  Control 
(probably  the  most  prevalent).  Assumption  and  Transfer. 

The  process  outlined  here  should  provide  the  program  manager  a  systematic  method 
to  assess  risks  and  define  appropriate  actions  to  assure  decision  liters  that  the  program 
risks  are  at  an  appropriate  level  to  proceed  to  the  next  phase  of  development  It  should  also 
be  pointed  out  that  risk  management  is  not  a  stand-alone  or  add-on  activity  in  system 
acquisition.  It  is  an  integral  part  of  the  program  management  process  which  includes: 
Systems  Engineering,  logistics  support,  manufacturing  management,  software 
development,  acquisition  strategy,  and  cost  estimating.  Conversely,  the  activities 
conducted  within  each  of  these  areas  are  in  essence  risk  management  activities  and 
techniques. 
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10-0  TRADE  STUDIES  AND  EFFECTIVENESS  ANALYSIS 


10-1  Trade-Off  Analysis 

Ttade-Off  Analysis  is  a  formal,  technically  based  decision  analysis  method  used  for 
resolving  conflicts  and  making  choices  among  viable  alternative  solutions  associated  with: 

( 1 )  competing  requirements  and  constraints; 

(2)  system  concept  functions  and  allocations;  and 

(3)  connguration  management  and  design  synthesis  issues  associated  with 
systems,  subsystems  and  configuration  items  and  interfaces. 

During  the  earlier  stages  of  the  program,  trade-offs  will  piinuuily  be  made  at 
relatively  liigh  levels  of  abstraction.  For  example,  trade-offs  among  comj^ting  system 
concepts  that  might  be  employed  to  accomplish  the  mission  need.  During  later  stages  of  the 
program  the  trades  will  be  made  at  much  lower  levels,  for  example  trade-offs  among 
competing  subsystems  or  even  trade-offs  among  specific  components  that  can  acct^lish 
SOUK  spe^c  function  within  a  system  or  subsystem.  In  all  cases  these  trade-offs  involve 
decisions  that  consider  the  performance  capability  of  the  item  involved  in  the  context  of  the 
cost  and  effectiveness  of  that  particular  item. 


10-2  Elements  of  the  Trade-0^  Process. 

A  Trade-Off  process  requires  a  rational,  objective  and  repeatable  methodology  to 
support  decision  making.  A  typical  TVade-Off  Analysis  (TOA)  Methodology  involves: 

(1)  problem  definition; 

(2)  review  and  understanding  of  user  requirements; 

(3)  selection  of  the  TOA  methodology  and  evaluation  criteria: 

(4)  identification  and  selection  of  the  problem  solving  alternatives; 

(5)  development  of  models  and  measurement  of  the  performance  of  the  various 
alternatives; 

(6)  analysis  of  results,  including  selection  of  the  preferred  alternative  and  the 
conduct  of  a  sensitivity  check  (sensitivity  analysis);  and 

(7)  documentation  of  the  process  and  results  for  future  examination  and  use. 
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10-3  Effectiveness  Analysis 

Effectiveness  analyses  are  required,  in  key  areas,  to  ensure  a  system  meets 
customer  needs  and  provides  a  balanced  set  of  products  and  processes.  Effectiveness 
analyses  evolve  from  the  primary  life  cycle  functions  mentioned  in  MIL-STD-499. 
Effectiveness  analyses  may  involve  any  of  the  following: 

-  Manufacturing 

*  Verification 

>  Deployment 

-  Operations 

-  Support 

-  Training 

-  Disposal 

-  Environment 

~  Life  cycle  cost 

Effectiveness  analyses  are  used  to: 

( 1 )  support  identification  of  mission  and  performance  objectives  and  requirements, 

(2)  support  the  allocation  of  performance  to  functions, 

(3)  provide  criteria  for  the  selection  of  solutimi  alternatives, 

(4)  provide  analytic  confirmation  that  designs  satisfy  customer  requirements,  and 

(5)  support  product  and  process  veritication. 

Various  effectiveness  factors  can  be  used  to  characterize  the  performance  of  a 
system.  These  include  various  figures-of-merit  for  cost-system  effectiveness,  operational 
availability  (Aq),  logistic  support  effectiveness,  mean  time  between  maintenance  actions 
(MTBM),  mean  time  between  failures  (MTBF),  mean  time  to  repair  (MTTR),  facility  use 
(in  percent),  required  maintenance  skill  levels  and  tasks,  facility  use  (in  %)  and  other  like 
factors.  The  particular  set  of  effectiveness  factors  that  are  select^  to  characterize  a  system 
depends  on  the  critical  needs  for  the  operation  and  support  of  that  particular  systetiL  Note 
that  the  effectiveness  factors  listed  above  fit  into  various  system  functional  categories  listed 
below  and  are  identilied  by  conductin|;  effectiveness  analyses  against  the  primary  system 
functions.  System  functional  effectiveness  can  usually  relate  to  various  op^tional 
requirements  originally  established  through  examining  various  mission  scenarios.  Many  of 
the  effectiveness  factors  selected  are  candidate  technical  performance  measures  to  be 
tracked  during  the  development  program  to  assess  progress. 
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11-0  TECHNICAL  PERFORMANCE  MEASUREMENT 


11-1  General 

The  need  for  performance  measurement  is  established  by  DODI  5000.2  and 
MIL-STD-499.  Technical  Performance  Measurement  (TPM)  is  one  of  the  techniques  for 
conducting  systems  analysis  and  establishing  technic^  management  control,  which  are 
among  the  major  activities  that  comprise  the  Systems  Engineering  process.  TPM  is 
coiiq)lementary  to  the  C/SCSC  system  for  determining  the  technical  status  of  development 
If  measurements  are  properly  scheduled,  TPM  provides  the  Program  Manager  with  the 
technical  status  of  critical  tecimical  parameters  in  a  timely  manner  so  that  corrective  actions 
can  be  taken. 

TPM  evaluation  is  usually  conducted  during  a  design  review.  TPM  evaluation  may 
be  accomplished  at  other  milestones  such  as  significant  test  events  or  as  directed  by  the 
Program  Manager. 

TPM  is  concerned  with  evaluating  the  adequacy  of  a  Configuration  Item  design  to 
satisfy  the  system  performance  requirement  specification.  As  such,  the  parameters  selected 
for  technicid  performance  measurement  must  (1)  be  important  indicators  of  the  eventual 
technical  success  of  the  entire  system,  (2)  be  measurable,  and  (3)  have  an  associated 
performance  proEle  indicating  anticipated  future  performance  over  the  time  period  of 
mterest 

In  essence,  TPM  is  employed  to  identify  and  flag  a  Configuration  Item  (Cl)  design 
deficiency  that  might  seriously  endanger  meeting  a  critic^  system  performance 
requirement.  If  a  technical  performance  deficiency  is  flagged,  an  analysis  must  be 
performed  to  determine  the  cause  and  to  assess  the  impact  on  higher  level  parameters. 
Alternate  recovery  plans  must  then  be  developed  and  cost,  schedule  and  performance 
impacts  must  be  fully  explored.  If  performance  is  in  excess  of  requirements,  opportunities 
for  reallocation  of  requirements  and  resources  are  assessed. 

Technical  performance  measurement  is  fundamentally  rooted  in  the  conc^t  that 
management  control  is  established  by  selecting  key  parameters  to  be  tracked,  estimating  the 
future  behavior  of  those  parameters  over  a  period  of  time,  then  tracking  actual  performance 
against  estimated  values  and  using  the  degiW  of  variation  from  estimated  values  to  identify 
the  need  for  management  attention.  In  this  sense  TPM  is  no  different  than  most  of  the  other 
performance  based  management  techniques  familiar  to  DoD  managers. 


11-2  Technical  Performance  Measurement  (TPM)  Profile 

A  TPM  Profile  is  a  plot  that  depicts  the  performance  of  a  specific  TPM  parameter 
throughout  the  program. 

Relevant  terms  and  relationships  used  in  a  TPM  profile  are  described  below: 

Achievement  to  Date.  Measured  progress  or  estimate  of  progress  plotted  and 
compared  with  planned  progress  at  designated  milestone  dates. 

Current  Estimate.  The  value  of  a  technical  parameter  that  is  predicted  to  be 
achieved  with  existing  resources  by  the  end  of  the  contract 
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Milestone.  Point  in  time  when  a  TPM  evaluation  is  accomplished.  Evaluations 
are  typically  scheduled  to  support  technical  reviews,  significant  test  events,  and 
may  also  suppon  cost  reporting  intervals. 

Planned  Value.  Predicted  value  at  the  time  of  measurement  based  on  the  planned 
profile. 

Planned  Profile.  Profile  representing  the  projected  performance  of  the  selected 
parameter. 

Tolerance  Band.  Management  alert  limits  placed  on  either  side  of  the  planned 
profile  indicating  the  degree  of  variation  allowed.  Represents  projected  estimating 
error. 

Threshold.  The  limiting  acceptable  value  of  a  technical  parameter,  usually  a 
contractual  requirement. 

Variation.  Difference  between  the  planned  value  of  the  selected  parameter  and  the 
achievement-to^ate  derived  fixim  a^ysis,  test,  or  demonstration. 


nCHNlCAL 

PARAMEISR 

VALUES 


Figure  1 1-2  Typical  Technical  Performance  Measurement  Profile 

Figure  11-2  presents  a  typical  performance  profile  illustrating  the  use  of  the  terms 
defined  above.  TPMs  comprise  an  important  element  of  the  Risk  Management  process. 
OWy  key  parameters  are  selected  as  TPMs  to  be  tracked  throughout  the  program.  These  are 
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usually  broad  and  critical  parameters  that  provide  insight  into  important  aspects  of  the 
health  of  the  program.  Candidate  TPMs  include  ove^l  weight  of  the  amnaft  or  the 
avionics  suite  (always  a  critical  parameter ).  reliability  expressed  as  mean  time  between 
failures  (MTBR,  or  repairability  expressed  as  mean  time  to  repair  (MTTR).  To  explain  the 
use  of  the  TPM,  consider  Figure  6.  representing  for  example  the  MTBF  of  the  avionics 
suite.  TTic  Threshold  value  shown  is  the  specified  minimum  acceptable  value  of  MTBF  for 
the  avionics  suite  established  by  the  contraa.  The  area  above  the  Threshold  is  the  favorable 
region  and  that  below  the  Hireshold  is  designated  as  the  unfavorable  region.  At  the  stan  of 
the  program  the  estimate  for  MTBF  is  shown  to  be  in  the  favorable  region  just  above  the 
Thr^hold.  The  Current  Estimate  is  the  estimate  of  the  system  MTBF  to  be  achieved  at  die 
conclusion  of  the  program  based  on  the  current  rate  of  progress.  The  Planned  Profile  is 
shown  as  a  linear  plot  from  the  initial  value  to  the  Current  Estimate.  The  Profile  may  have 
any  shape  depending  on  the  parameter  and  acdons  taken  during  a  particular  program  phase 
that  affect  the  TPM  in  question.  A  Tolerance  Band  is  established  on  both  sides  of  the 
Planned  Profile  to  establish  a  practical  tolerance  level  for  the  TPM.  Achievement  to  date  is 
a  current  measure  of  the  TPM  usually  taken  agmnst  a  program  milestone  (such  as  a 
technical  review  or  audit)  or  as  part  of  a  periodic  reporting  process.  Variation  is  the 
difference  between  the  planned  value  for  the  TPM  and  the  actual  value  (achievement  to 
date).  TPMs  are  used  as  pan  of  a  management  by  exception  technique  which  is  invoked 
when  a  TPM  value  fails  outside  the  Tolerance  Band.  When  the  value  falls  in  the 
unfavorable  region,  the  risk  is  assessed  and  previous  contingency  plans  are  acted  upon  (or 
a  contingency  plan  is  prepared  if  none  previously  existed).  If  the  value  falls  outside  the 
proEle  on  the  favorable  side  it  may  be  j^ssible  to  reallocate  program  resources  from  this 
TPM  to  others  that  reflect  an  unfavorable  prognosis.  Used  in  thus  way  the  TPM  process 
becomes  an  important  part  of  program  Risk  Management 
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12-0  TECHNICAL  REVIEWS  AND  AUDITS 


12-1  General 

Technical  reviews  are  an  integral  and  essential  part  of  the  acquisition  process. 
Reviews  range  from  very  formal  technical  reviews  by  government  and  contractor  engineers 
to  informal  reviews  concerned  with  product  and  task  element  of  the  work  breakdown 
structure  (WBS)  that  involve  only  a  few  directly  concerned  personnel. 

MIL-STD-499B  advocates  a  revised  approach  to  technical  reviews  and  audits.  The 
use  of  incremental  reviews  is  proposed  to  provide  increased  efficiency  to  the  entire  review 
process.  The  proposed  approach  depends  heavily  on  the  development  and  utilization  of  an 
Engineering  that  is  structured  to  efficiently  supp^  the  Systems  Engineering  Process. 
The  WBS  is  then  used  as  a  basis  for  tlic  formation  of  integrated  product  teams  for  each  of 
the  elements  of  the  V^S.  Teams  are  assigned  to  each  of  the  levels  of  the  WBS  that  arc 
appropriate.  The  IPT  approach  suppons  the  use  of  incremental  technical  reviews  and 
audits.  Much  of  the  review  activity  at  the  lower  level  WBS  elements  is  accomplished 
through  team  reviews  and  regular  meetings.  Major  reviews  can  be  managed  by  having  a 
series  of  incremental  reviews  at  subsystem  and  functional  levels.  As  reviews  at  the  lowest 
reviewable  level  are  completed,  the  incremental  reviews  can  proceed  to  higher  and  higher 
levels  in  the  Engineering  WBS.  When  the  major  reviews  such  as  the  PDR  and  the  CDR  are 
conducted,  they  consist  largely  of  demonstrations  of  compliance  reflecting  the  earlier 
reviews  at  lower  levels.  In  this  manner  it  hop^  to  avoid  the  large  scale  reviews  wimessed 
in  major  system  programs  when  hordes  of  reviewers  descend  upon  a  contractor  to  conduct 
simultaneous  reviews  of  all  key  program  elements  usually  breal^j  into  "splinter  groups  of 
specialists  reviewing  each  significant  program  element.  Reviews  of  this  type  arc  not 
usually  very  efficient,  suffer  hrom  poor  communications  at  a  full  program  level  and  usually 
take  a  considerable  time  period  to  identify  and  resolve  the  most  important  issues.  The 
incremental  review  process  promises  to  make  such  reviews  considerably  more  efficient  and 
effective. 


12-2  Reviews  and  Audits  Under  MIL-STD-499B 

MIL-STD-499B  includes  a  description  of  the  Technical  Review  and  Audit 
procedures  to  be  followed  in  support  of  the  System  Engineering  Erocess.  Appendix  C  of 
Draft  MIL-STD-499B  (5/6/92)  is  entitled  General  Guidance  On  The  Conduct  of  Technical 
Reviews.  In  this  appendix,  MIL-SID-lSZl  is  referenced  but  complete  guidance  for 
reviews  to  be  utilized  and  the  criteria  for  each  are  provided. 

Reviews  under  MIL-STD-499B: 

( 1 )  Alternate  System  Review  (ASR) 

(2)  System  Requirements  Review  (SRR) 

(3)  System  Functional  Review  (SFR) 

(4)  Preliminary  Design  Review  (PDR) 

(5)  Critical  Design  Review  (CDR) 

(5)  System  Verification  Review  (SVR) 

(6)  Functional  Configuration  Audits  (FCA) 

(7)  Physical  Configuration  Audits  (PCA) 
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Criteria  is  provided  for  each  of  the  review  types  listing  the  System  Engineering 
Master  Schedule  entry  accomplishment  appropriate  for  the  review  and  its  specific 
acquisition  phase.  Also  listed  are  the  exit  accomplishments  that  are  necessary  for  the 
successful  completion  of  the  review  or  audit.  Emphasis  on  the  Incremental  review  process 
is  added  by  describing  additional  review  types  that  support  it.  These  reviews  include 
Subsystem  Reviews,  Functional  Reviews  and  Interim  System  Reviews.  The  process 
encourages  extensive  use  of  IPTs  mapped  into  the  elements  of  the  Engineering  WBS  as  a 
means  of  utilizing  incremental  reviews  to  improve  the  perfomiance  of  the  entire  Technical 
Reviews  and  Audits  process. 


page  38 


Volume  2:  Avionics  Systems  Engineering 


13-0  CONFIGURATION  MANAGEMENT 


13-1  The  Central  Role  of  Configuration  Management 

A  primary  ourp'  i  of  the  Systems  Engineering  process  is  a  technical  data  package 
containing  engineer  ng  drawings,  associated  lists,  process  descriptions,  specifications  and 
interface  documents  which  together  define  the  physical  geometry,  material  composition, 
performance  characteristics,  manufacture,  assembly,  and  acceptance  test  procedures. 
C^nriguration  management  includes  the  function  of  identification  of  products  and  processes 
to  bp  controlled  (through  specifications,  drawings,  etc.),  change  control  (ECPs,  etc.), 
str.nis  accounting,  and  audits  (verification). 

Interface  management  is  an  integral  part  of  configuration  management.  Interface 
management  includes  internal  and  external  interface  definition,  interface  control, 
compatibility  assessment,  and  interface  coordination  through  an  Interface  Working  Group 
(IWG)  or  an  Interface  Control  Working  Group  (ICWG).  Effective  Interface  management 
is  a  major  factor  in  the  effective  integration  of  large  scale  systems. 

Another  aspect  of  configuration  management  is  Technical  data  management. 
Technical  data  management  administers  the  development,  control,  release,  and  deiivciy  of 
required  technical  data. 


13-2  The  Use  of  Configuration  Baselines 

A  configuration  identification  document  or  a  set  of  such  documents  formtdly 
designated  by  the  (iovemment  at  a  specific  time  during  the  life  cycle  of  a  Configuration 
Item  (Q)  is  called  a  configuration  baseline.  Baselines,  plus  approved  changes,  constitute 
the  current  approved  configuration  documentation.  Configuration  baselines  arc  used  to 
ensure  an  orderly  and  controlled  transition  from  one  major  conomitment  point  (milestone 
decision)  to  the  next.  For  configuration  management  purposes  there  are  three  baselines, 
which  arc  established  sequentially: 

Functional  Baseline:  The  initially  approved  documentation  describing  the 
functional  characteristics  of  a  system  or  Cl  and  the  verification  means  requir^  to 
demonstrate  the  achievement  of  those  characteristics.  It  is  initially  drafted  near  the 
end  of  the  Concept  Exploration  &  Demonstration  (CED)  phase  with  the 
System/Segraent  Specification  (Type  A)  and  established  by  Government  approval 
and  contract  implementation  early  in  the  Dem  &  Val  phase,  but  no  later  ^an  the 
System  Design  Review  (SDR).  This  baseline  is  the  foundation  for  configuration 
management  by  the  Government  during  subsequent  phases  of  the  program. 

Allocated  Baseline:  The  initially  approved  documentation  describing  a  Cls 
functional  and  interface  characteristics  that  arc  allocated  fiom  those  of  a  higher  level 
Cl,  with  verification  required  to  demonstrate  the  achievement  of  the  specified 
functional  and  interface  characteristics.  This  baseline  is  documented  in  Type  B 
Specifications  and  related  documents.  For  hardware  configuration  items  (HWCIs), 
the  timing  of  the  establishment  of  this  baseline  will  be  agreed  upon  between  tlie 
contractor  and  the  contracting  agency  and  will  take  place  during  the  Engineering  & 
Manufacturing  Development  (EMD)  phase.  There  are  significant  variations  on 
policy  regar^ng  the  timing  of  the  establishment  of  the  allocated  baseline  among 
services.  For  computer  software  configuration  items  (CSCIs),  the  allocated 
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baselinf;  is  typically  established  upon  completion  of  the  Software  Specification 
Review  (SSR),  although  timing  may  again  vary  by  service.  Tnis  baseline  is  used  to 
govern  the  development  of  the  selected  Cl's  that  are  allocated  from  system 
requirements,  or  that  are  a  pan  of  a  higher  level  Cl. 

Product  Baseline:  The  initially  approved  documentation  describing  all  the 
necessary  functional  and  physical  characteristics  of  the  Cl,  any  required 
joint/combined  operations  inter  operability  characteristics,  and  the  selected 
characteristics  designated  for  production  acceptance  resting.  This  baseline, 
documented  by  a  Type  C  Specification  with  accompanying  Type  D  (Process)  and 
Type  E  (Material)  Specifications  plus  engineering  drawings  and  detailed  design 
documentation,  evolves  for  each  Cl  from  the  corre^nding  Type  B  Specification. 
The  Product  Baseline  is  established  by  the  Government  upon  completion  of  the 
Physical  Configuration  Audit  (PCA).  The  product  configuintion  documentation  is 
us^  to  prescribe  the  necessary  "build  to"  or  "form,  fit,  and  function"  requirements 
and  the  acceptance  tests  for  those  requirements.  The  degree  of  detail  required  is 
dependent  upon  anticipated  methods  of  extended  procurement  and  for  logistics 
support  of  potentially  reparable  components  of  the  item. 


13-3  The  Roles  of  the  Government  and  the  Contractor  in 
ConHguration  Management. 

In  the  Statement  of  Work,  the  Government  tasks  the  contractor  to  perform  the 
following  four  functions  of  configuration  management: 

(1)  Identify  and  document  the  functional  and  physical  characteristics  of  the 
confrguration  items. 

(2)  Control  changes  to  configuration  items  and  their  related  documentatim. 

(3)  Record  and  report  information  needed  to  manage  configurations  effectively, 
including  the  status  of  proposed  changes  and  the  implementation  stams  of 
approved  changes. 

(4)  Audit  configuration  items  to  verify  conformance  to  specifications,  drawings, 
interface  control  documents,  and  oAer  ctmtract  requirements. 

The  Government  perfoims  this  tasking  by  selectively  tailoring  the  specific  requirements  of 
MIL-STD‘973.  \^ile  most  configuration  management  tasks  are  actually  {formed  by  the 
prime  cond*actor,  many  of  the  tasks  involve  making  recommendations  which  the 
Government  may  or  may  not  accept,  e.g.,  desig>iation  of  (Ts,  configuration  changes,  etc. 
Some  other  tasks  are  performed  jointly  by  the  prime  contractor  and  the  Government,  e.g., 
audits  and  assignment  of  document  numbm  and  nomenclature. 
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14-0  SOFTWARE  SYSTEMS  ENGINEERING 


Software  engineering  must  be  integrated  into  the  overall  Systems  Engineering  effort  and 
not  be  considered  separately.  See  Volume  1,  .section  9,  for  additional  details. 


15-0  SUPPORTABILITY  ENGINEERING  UNDER  THE  SE 
PROCESS 


15-1  General 

Supponabiiity  engineering  is  an  important,  multi-faceted  engineering  discipline  that 
must  be  integrated  under  the  Systems  Engineering  umbrella,  not  considered  separately. 
This  requires  that  the  multi-disciplinary  Integrated  Product  I^velopment  Teams  (IPD’U 
defined  in  both  Systems  and  Concurrent  Engineering  must  include  engineering 
representation  from  the  many  elements  that  comprise  supponabiiity.  Supponabiiity 
management  is  embodied  in  the  Integrated  Logistics  Support  Plan  (ILSP)  which  is  usually 
ini^t^  during  conceptual  design  and  is  updated  in  preliminary  design.  Logistics  suppon 
activities  that  are  performed  throughout  the  system  life  cycle  as  pan  of  Systems 
Engineering  is  shown  in  Figure  15-3. 


15-2  Support  Environment 

It  is  important  to  define  the  suppon  environment  for  the  system  under  development 
The  system  suppon  environment  must  be  compatible  and  consistent  with  Heet  operations. 
For  avionics  systems  this  usually  means  compatibility  with  the  Aircraft  Carrier  envianment 
and  Carrier  operations.  In  general.  Gamers  have  little  excess  space  for  storage  of  spare 
parts.  The  sparing  concept  (as  an  example)  must  be  a  major  consideration  in  many  of  the 
design  decisions  made.  Because  of  the  C^airier  environment,  configuration  management  is 
of  major  importance.  With  the  many  aircraft  t^s  that  must  lx  supported  aboard  an 
Aircraft  Cairier,  many  avionics  systems  configurations  for  each  type  can  severely 
exacerbate  the  problem  leading  to  a  logistics  nightmare. 

Supponabiiity  concerns  must  consider  the  levels  of  maintenance  provided  for  the 
avionics  system.  Modem  avionics  design  has  attempted  to  move  towards  a  two  level 
maintenance  concept  eliminating  the  Intermediate  or  "I"  level.  In  the  Joint  Integrated 
Avionics  Working  Group  (JIAWG)  standardization  efforts,  two  level  maintenance  has  been 
the  goal  with  strong  Air  Force  support.  Two  level  maintenance  is  difficult  to  implement 
hilly  on  an  Aircraft  Carrier  with  limited  availalnlity  of  storage  space  for  spare  parts. 


15-3  Integrate  Support  Concepts  into  Systems  Engineering 
Guidelines 

Ensure  that  the  systems  engineering  process  defined  is  consistent  with 
supportability  needs.  Recognize  that  the  logistics  SupportabUity  Analysis  (LSA)  procedure 
is  part  of  the  SE  process  and  that  the  entire  integral^  Logistics  Support  (ILS)  approach  is 
in  reality  part  of  (or  at  least  closely  coupled  to)  the  SE  process. 
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Require  dial  supportability/logistics  engineers  and  all  supportability  specialties  be 
reprei^nted  as  part  of  the  muiti-discipUnary  integrated  product  teams  recommended  under 
systems  engineering  guidelines. 

Figure  lS-3  lists  the  logistic  support  activities  that  must  be  considered  in  the  system 
life  cycle  as  part  of  the  Systems  Engineering  process. 
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Figure  15-3  Logistic  support  activities  in  the  system  life  cycle. 

(from,  B.S.  Blanchard,  System  Engineering  Management,  with  pemission) 
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16-0  EFFECTIVE  USE  OF  COMPUTER  BASED  SYSTEMS 
ENGINEERING  TOOLS 


It  is  recognized  that  large  scale  (many  complex  and  interleaved  requirements) 
systems  employing  the  latest  generations  of  advanced  electronic/electro-optic  technologies 
require  the  use  of  modem  computer  tools  in  order  to  achieve  efficient  effective  designs  and 
to  intelligendy  choose  among  the  myriad  design  choices  that  arc  available.  The  avionics 
suite  for  a  modem  tactical  aircraft  employing  advanced  integrated  avionics  technologies  is  a 
prime  example  of  this  class  of  large  scale  systems. 

Tools  are  used  in  each  aspect  of  the  acquisition  process  horn  simulation  programs 
used  in  the  conceptual  phases  of  development  to  make  broad  stroke  weapon  systems 
decisions,  to  the  life  cycle  cost  models  u.sed  in  later  phases  to  compare  the  overall  costs 
through  the  expected  service  life  of  the  system  and  evaluate  the  projected  cost  effectiveness 
of  various  alternate  supportability/logistic  concepts. 

One  of  the  most  significant  advances  in  the  application  of  Systems  Engineering  is 
the  increasing  availability  and  use  of  computer  based  tools  for  all  phases  of  ^e  process. 
Analysis  and  design  tools  for  Systems  Engineering  are  available  for  elements  of  aU  of  the 
acquisition  phases.  Many  of  the  tools  were  originally  developed  to  support  the  Software 
development  task  as  Con^uter  Aided  Software  En^ecring  (CASE)  tools,  and  have  been 
extendi  to  Systems  Engineering.  A  need  to  establish  a  complete,  well  integrated  systems 
engineering  tool  set  is  very  important  to  die  effectiveness  and  efficiency  of  the  process,  (see 
also  Volume  1,  Section  9-3.5). 

17-0  CONCURRENT  ENGINEERING 

Concurrent  Eng^ineering  is  closely  related  to  Systems  En^neering  in  the  sense  that 
both  disciplines  require  that  all  elements  of  the  product  life  cycle  be  considered 
simultaneously.  Systems  Engineering  combined  with  Engineering  Management  and 
Automated  Tools  i^es  up  Concurrent  Engineering  (CE).  The  SEP  embodies  both  SE 
activities/tasks  and  Engineering  Management  to  control  the  development  effort  Integrated 
Product  Teams  (IP'fs)  also  enable  the  (^  effort. 
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18-0  SYSTEMS  ENGINEERING  FOR  MODULAR  AVIONICS 


18-1  General 

The  concept  of  Modular  Avionics  packaging  has  in  effect  created  the  basis  for  a  de 
facto  architecture.  Although  a  module  based  system  isn't  in  and  of  itself  an  architecture, 
the  choice  of  packaging  concept  provides  a  certain  physical  definition  to  the  architecture. 
At  present,  the  evolution  of  Standard  Electronic  Module  (SEM)  packaging  programs  has 
brought  us  to  the  era  of  the  SEM  "E"  module  profile;  a  module  that  is  approximately  6 
inches  by  6  inches  by  0.6  inch  thick. 

The  size  of  a  module  is  usually  a  compromise  based  on  the  current  state  of 
technology.  Choit  e  of  a  module  that  is  too  small,  allows  for  implementation  of  low  level 
functionality  for  each  module  providing  a  great  deal  of  functional  commonality  at  the 
module  level  bus  require  a  great  number  of  modules  and  a  large  number  of  external 
connections.  Choice  of  a  module  size  too  large  for  the  technology  will  allow  a  great  deal 
offimctionality  per  module  but  will  provide  little  commonality,  e.  g.  each  module  will  tend 
to  be  unique.  A  large  module  size  will  tend  to  minimize  external  connections  at  the  expense 
of  commonality. 

Modular  Avionics  provides  significant  impacts  to  Systems  Engineering.  As  a 
design  approach.  Modular  Avionics  defines  a  tailoring  to  the  Systems  Engineering  process. 
Modules  imply  and  enforce  a  system  partitioning  at  the  module  level.  With  significant 
experience  with  a  particular  module  format  (size  and  configuration)  comes  an  implications 
data  base  that  can  provide  an  enhanced  degree  of  confidence  in  design  pr^ctability.  For 
example,  reliability  of  an  electronics  module  can  be  related  to  power  dissipation  (total 
thermal  loading),  thermal  and  mechanical  environment  and  other  operational  conditions. 
For  a  given  power  dissipation  per  module  and  cooling  technique  employed,  data  can  be 
gathei^  from  operational  experience  and  used  to  predict  very  consistently  such  factors  as 
reliability,  total  avionics  weight,  and  backplane  data  bus  performance  when  the  sanoe 
module/bus  configurations  are  used  for  new  designs.  An  established  Modular  Avionics 
architecture  approach  makes  future  applications  more  effective  and  predictable  without 
severely  limiting  technological  enhancement  (at  the  module  level).  Avionics  noodular 
architectural  activities  are  described  below. 


18-2  JIAWG  Modular  Avionics 

JIAWG  Avionics  provides  for  a  major  transition  of  Avionics  systems  from  a  Federated 
"Black  Box"  architectural  approach  to  a  module  based  inte^ted  architecture.  Hgure  18-2 
provides  a  pictorial  depiction  of  this  transition.  The  architectural  approach  is  based  on  a 
great  investment  of  avionics  focused  R&D  funds  by  both  the  Navy  and  Air  Force  over 
se  '.’cral  decades. 

Military  use  of  the  module  concept  was  first  developed  and  demonstrated  by  the 
Navy  in  the  Poseidon  Program  and  transitioned  into  various  Standard  Electronic  Module 
(SEM)  and  Standard  Avionics  Module  (SAM)  implementations  through  the  years. 
Research  performed  under  the  Air  Force  "PAVE  PILLAR"  Program  and  the  Navy 
Advanced  Avionics  Technology  Demonstration  (AATD)  Program,  established  the  basis  for 
the  integrated  avionics  systems  and  the  fiber  optics  bus  developments  employed  in  the 
JIAWG  aircraft 
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Figure  18-2  Architectural  Transition  from  F^erated  to  Modular  under  JIAWG 

The  SEM  "E"  profile  has  been  adopted  for  the  bulk  oLthe  "common  avionics" 
digital  processing  peifoirned  on  JIAWG  aircraft  (F-22  and  RAH-66  currently).  Recent 
advances  in  microcircuit  densities  (sub-micron  feature  size)  has  resulted  in  power  densities 
of  80-90  watts  for  certain  F-22  modules.  Since  forced  air  cooling  can  accommodate  only 
about  40  watts  per  module  reliably  in  the  SEM  "E"  size,  F-22  has  been  forced  to  adopt 
liquid  flow  through  cooling  techniques  for  higher  power  modules.  Technology  advances 
towards  microcircuits  with  0.3  micron  feature  sizes  and  lower  will  continue  to  drive 
thermal  management  for  advanced  avionics  to  liquid  flow  through  cooling.  RAH-66  has 
managed  to  retain  air  cooling  by  limiting  circuit  density  on  SEM  "E"  modules  to  control 
power  dissipation.  It  appears  certain  that  both  conventional  air  and  conventional  liquid 
cooled  modular  systems  will  be  used  in  aircraft.  Two  SEM  "E"  module  variations  will 
undoubtedly  become  standard  in  future  generation  aircraft.  The  first  of  these  types  is  a 
conventional  SEM  "E"  in  which  cooling  is  by  conduction  to  a  thermal  manifold  (rail) 
cooled  by  air  or  liquid  flow  through  the  rail  structure,  limited  to  approximately  40  watts 
maximum  per  module.  The  second  type  provides  liquid  flow  through  the  modules  in 
which  the  cooling  liquid  (or  air)  is  forced  to  flow  through  passages  in  the  central  module 
core  and  providing  cooling  for  modules  dissipating  upwards  of  100  watts.  Both 
techniques  can  be  used  where  applicable  to  satisfy  a  wide  diversity  of  avionics 
requirements. 
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18-3  Integrated  Modular  Avionics 

Hailed  as  the  most  important  innovation  in  airline  avionics  in  20  years  is  the 
development  of  a  standard  modular  avionics  concept.  Designated  as  Integrated  Modular 
Avionics  (i^),  the  concept  introduces  a  standard  avionics  cabinet  enclosure  with  the  use 
of  Line  Replaceable  Modules  (LRMs).  This  integrated  appro^h  has  the  cabinet  repladng 
many  separate  black  boxes  and  enables  the  integrated  avionics  to  share  processing, 
memory,  I/O  functions  and  power  supply  generation.  This  concept  will  be  deployed  on  a 
full  scale  basis  in  the  future  Boeing  777.  Many  of  the  concepts  were  originated  in  die 
military  and  have  been  deployed  on  a  limited  scale  in  military  aircraft  for  many  years,  ^e 
IMA  concept  is  unique  in  that  all  of  the  standards  that  support  the  concept  are  being 
developed  together  in  the  same  relative  time  phasing  so  that  a  Systems  Engineering 
approach  can  be  taken  to  the  overall  standardization  effort  The  standardizadon  process  is 
inanagcd  by  the  Airlines  Electronic  Engineering  Conunittee  (AEEC)  as  a  replacement  for 
the  current  generation  ARINC  700  avionics.  Development  of  the  IMA  is  a  further  move 
iow&tds  digiud  ftvionics*  Employing  &  high  degree  of  software  controli  the  IMA  will 
employ  latest  versions  of  high  performance  microprocessors,  and  advanced  data  bus 
technology.  The  ovcsrall  architecture  is  defined  in  ARINC  Report  651.  Other  reports  that 
comprise  the  standards  include,  ARINC  629  data  bus,  ARINC  659  backplane  bus  and  the 
ARINC  429  databus.  TTie  airline  industry  has  fully  adopted  Ada  as  their  standard  Higher 
Order  Language  because  of  the  rigor  it  provides  the  software  develc^ment  process.  The 
AEEC  standards  organizations  are  participants  in  the  Ada  9X  revision  process  and  look 
forward  to  the  release  of  the  revis^  standard.  Other  standards  that  comprise  tiie  IMA 
architecture  include: 

ARINC  609,  Design  Guidance  for  Aircraft  Electrical  Power  System; 

ARINC  613,  Guidance  for  Using  the  Ada  Programming  Language  in 
Avionics  Systems; 

ARINC  652,  Guidance  for  Avionics  Software  Management; 

ARINC  653,  Standard  Application  Software  Environment 

ARINC  653,  is  of  particular  interest  since  it  is  an  attempt  to  describe  the 
functionality  of  the  IMA  Operating  System,  as  well  as  describe  the  interface  between  the 
Operating  System  and  each  of  the  applications  that  use  the  Operating  System  services. 
Many  of  these  standards  are  still  under  development  with  full  standards  development 
scheduled  fort  completion  in  the  1^5- 1996  time  name. 
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19-0  TQM  AND  THE  SYSTEMS  ENGINEERING  PROCESS 

Total  Quality  Management  (TQM)  initiatives  and  other  ongoing  initiatives  for 
process  improvement  should  be  incorporated  with  the  Systems  Engineering  Process. 
Because  of  ongoing  emphasis  throughout  the  federal  government  on  productivity 
enhancement,  there  has  been  a  “general  conditioning’*  to  focus  on  quality,  productivity 
enhancement  and  effective  teaming  of  all  participants.  Emphasis  on  the  needs  of  the 
customer,  and  the  total  involvement  of  all  employees  as  “stakeholders”  in  a  team  process 
are  TQM  principles  that  are  very  much  in  concert  with  modem  Systems  Engineering 
practice.  Viewing  Systems  Engineering  as  the  technical  element  in  an  overall  TQM 
process  should  ease  the  acceptance  of  systems  engineering  as  part  of  an  overall  process 
improvement  initiative.  Because  industry  which  serves  the  military  avionics  market  has 
been  exposed  to  TQM  principles;  invoking  Systems  Engineering  concepts  through  TQM 
programs  should  be  equally  well  supported  by  the  commercial  industry  that  serves  the 
military  avionics  market  One  contractor  (Harris  Corporation)  has  used  TQM  process 
with  employee  participation  to  develop  and  achieve  consensus  for  a  Systems  Engineering 
Process  to  be  employed  throughout  the  corporation. 
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20-0  PRODUCT  IMPROVEMENT 


20-1  General 

Systems  Engineering  must  specifically  address  needs  of  product  improvement 
developments.  I’roduct  improvement  effons  include  retrofits,  upgrades  and  planned 
Pnxiuct  Improvement  (P^I)  programs.  The  discussion  below  ad^sses  the  application  of 
Systems  Engineering  in  product  improvement 


20-2  The  Role  of  Systems  Engineering  in  Product  Improvement 
Programs 

Systems  Engineering  plays  a  major  role  in  product  improvements,  both  during 
development  and  during  post-pioduction  operations  and  support  phases. 

There  are  several  strategies  by  which  a  system  may  be  improved  during  its  life 
cycle;  all  require  a  disciplined  application  of  the  Systems  Engineering  process  if  the 
improvement  is  to  be  made  in  the  most  effective  and  efficient  manner.  A  need  for  future 
improvements  may  be  foreseen  early  in  the  initial  stages  of  the 

program,  and  in  such  cases  the  acquisition  strategy  should  be  formulated  to  include 
product  improvement  as  an  integral  aspect  of  the  system  acquisition.  Product 
improvements  of  this  type  typically  M  into  one  of  the  following  categories: 

Pre-Planned  Product  Improvement.  A  relatively  low  risk  development  is 
planned  based  upon  the  technology  available  at  the  time,  with  the  understanding  that  more 
advanced  technology  will  be  integrated  into  tlie  system  when  it  becomes  available  during 
the  latter  developirtem  stages. 

Evolutionary  Acquisition.  Often  employed  in  C^I  systems  and  other  highly 
software  intensive  systems  where  requirements  are  impossible  to  define  with  certainty  in 
advance  of  user  employment  in  the  fielded  environment.  A  core  capability  is  initiallv 
fielded,  then  improvements  are  added  as  they  become  feasible,  (often  thn>U|;h  block 
upgr^s)  and  opCititional  requirements  become  more  completely  understood.  Thu  type  of 
a^uisition  has  application  to  advanced  avicmics  systems  as  well.  Core  Avionics  capability 
is  necessary  with  the  first  operational  deployment.  Improvements  in  Mission  Avionics  can 
evolve  over  rime  as,  for  example,  Iroprov^  algorithms  for  Sensor  Fusion  are  developed 
and  applied.  In  this  example  Ae  bulk  of  the  improvements  are  implemented  in  software, 
requiring  litde  change  to  the  physical  configuration  (hardware)  of  the  avionics  suite. 

(Changes  and  improvements  are  also  made  to  systems  as  they  progress  through  the 
normal  stages  of  development  prior  to  fielding  the  system.  When  Aese  changes  have  not 
been  explicitly  anticipated  and  planned  for  in  the  acquisition  strategy  as  discussed  above, 
they  generally  take  the  form  of  Engineering  Change  Proposals  (ECPs)  and  block  changes 

After  the  system  has  been  deployed,  product  improvement  typically  takes  the  form 
of  Modifications  and  Block  Changes.  The  decision  authority  overseeing  the  effort  may 
elect  to  have  the  system  being  m^fied  enter  into  either  Phase  II  or  HI  of  the  Systems 
Acquisition  Process. 
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RegEu^ess  of  the  type  of  product  improvement  undertaken,  the  role  of  Systems 
Engineering  remains  the  same  as  during  the  normal  product  development  cycle.  That  is, 
given  a  set  of  input  states,  conditions,  and  constraiints,  all  activities  of  the  Systems 
Engineering  process  (Requirements  Analysis,  Functional  Analysis  and  Allocation, 
followed  by  Synthesis,  managed  through  Systems  Analysis  and  Control)  are  en^loyed  to 
achieve  a  balanced  system  as  the  eventual  output.  The  process  is  an  orderly  problem 
solving  approach  applied  iteratively  and  recursively,  with  the  level  of  dettul  involved 
dependent  upon  the  level  of  development  undertaken.  If  anything,  it  is  even  more 
important  that  a  well  developed  Systems  Engineering  approach  be  taken  to  post-production 
modification,  because  many  of  the  problems  typical  of  modifications  to  deployed  systems 
are  often  more  complex  than  the  ori^nal  devel^ment  itself. 


20-3  Avionics  Experience  in  Product  Improvement  Programs. 

General 

Upgrades  offer  significantly  different  problems  than  do  so  called  “clean  sheet”  new 
designs.  It  is  recommended  that  any  SE  Avionics  revisions  based  on  the  findings  of  this 
review  make  provision  for  upgrades  (generic  and  as  specific  as  can  be  projected)  as  part  of 
the  initial  design  process.  Often  specific  retrofits  have  not  been  considered  as  part  of  the 
original  avionics  development.  As  a  result,  "interface"  provisions  have  not  been  put  into 
pla^  and  have  to  be  added.  This  is  very  costly  and  must  be  avoided  when  possible. 


20-2.:  MIL-STD-1553  (Standard  Avionics  Data  Bus) 

Special  requirements  exist  for  aircraft  developed  prior  to  the  almost  universal  use 
of  MIL-STD-1S53  A/B  as  the  standard  data  bus.  These  aircraft  employ  no  standard  data 
transfer  interface  and  suffer  from  a  proliferation  of  arbitrary  single  puipose  point-design 
interfaces.  Retrofit  to  such  aircraft  may  be  made  more  dimcult  because  of  the  lack  of  a 
standard  digital  data  bus.  Adoption  of  MBL'STD-1553  as  the  standard  military  avionics 
data  bus  made  a  remarkable  change  in  avionics  integration.  This  bus  provides  a 
standardized  control  interface  and  is  an  effective  integration  tool  for  avionics  systems. 
Many  aircraft  developed  prior  to  the  use  of  “1553”  have  later  incorporated  this  bus  in 
painnilly  expensive  stages  (The  F-14  aircraft  is  one  such  example). 


20-2.2  Standard  High  Speed  Data  Bus 

With  MIL-SID-  15S3B  as  an  example,  the  military  focused  on  the  development  of  a 
higher  performance  data  bus  commensurate  with  the  data  flow  needs  of  newer  generations 
of  signal  and  data  processors.  Work  in  the  SAE  Avionics  Systems  Division  (ASD),  the 
organization  that  prepared  and  reviews  MlL-STD-l^I^'  ^B,  initiated  development  of  a  next 
generation  high  performance  data  bus  as  a  follow-on  to  MIL-STD-1S53B.  This  effent 
brought  the  aerospace  industry  together  with  militap'  en^eers  (from  the  three  Services)  to 
develop  a  new  standard.  *^18  effon  started  with  a  requirements  (military  avionics) 
definition  phase  and  evaluated  many  data  formats,  bus  acquisition  techniques  and  protocol 
types.  The  result  was  the  preparation  of  two  standards,  bodi  operating  at  ^100  Mb/s  rates 
(compared  to  a  1  Mb/s  rate  for  MIL-STD-1553B)  and  both  employing  a  'Token  Passing" 
protocol  but  different  distribution  topologies.  Tlie  SAE  issued  two  high  speed  data  bus 
(HSDB)  standards,  one  for  a  "linear"  topology  and  the  other  for  a  "ring"  topology.  The 
JIAWG  (F-22,  RAH-66  and  A/FX)  aircraft  both  introduce  new  high  performance  data 
buses  ba^  on  the  SAE  Linear  HSDB  standard  while  retaining  M1L-STD-1553B  for  basic 
command/control  functions  and  low  data  rate  information  transfer.  It  is  unlikely  that  any 
new  aircraft  will  ever  be  developed  without  use  of  M1L-STD-1553B  and/or  a  combination 
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of  Standard  networks  and  buses  that  provide  a  flexible  interface  for  signal/data  connectivity. 
Futme  retrofits  will  take  advantage  of  the  standard  networks/bus  infrastructure  now  being 
established  to  ease  engineering  and  integradon  costs. 

20-2.3  Modular  Avionics 

New  retrofits  of  federated  “black  box"  avionics  systems  are  looking  toward  the  use 
of  advanced  modular  packaging.  The  Air  Force  Modular  Avionics  System  Architecture 
(MASA)  program  has  investigated  this  twe  of  upgrade  and  has  established  certain 
guidelines.  Any  avionics  tailoring  of  MIL-STD-49<>B  should  include  guidelines  for  these 
generic  upgrade  cases.  The  JIAWG  aircraft  in  development  and  the  Navy  SHARP 
program  ^so  make  a  great  deal  of  modular  packaging  R&D  available  for  avionics 
applications.  Standardise  modular  avionics  design  can  ease  the  costs  of  retrofit  In  future 
aircraft  employing  a  standard  modular  avionics  packaging  scheme  with  standard  connector 
pin-outs  and  standard  backplane  buses,  retrofit  electronics  may  consist  of  adding  a  module 
(or  a  few  modules)  in  an  existing  "integrated  rack  or  equipment  enclosure.  Where  aircraft 
apertures  (usually  customized  to  the  aircraft  physical  configuration)  are  involved  in  the 
retit>fit  the  design  can't  be  completely  standardized,  but  overall  costs  should  be  better 
predicted  and  controlled. 

20-2.4  Global  Positioning  System  Retrofits 

One  of  the  most  significant  recent  experiences  in  product  inqjrovenoent  is  concerned 
with  retrofit  of  the  Global  Positioning  System  (GPS)  into  several  Navy  piatforms.  Costs 
of  the  engineering  design  development  necessary  for  the  retrofit  in  each  of  the  selected 
aircraft  were  (in  each  instance)  larger  than  the  total  procurement  costs  of  the  equipment 
installed. 

Although,  the  "Up  Front"  engineering  costs  were  derived  from  complex  and 
^versc  factors,  in  large  measure  they  can  be  attributed  to  a  lack  of  consistency  in  the 
interface  standards  used  among  the  am^t.  Iliis  lack  of  standard  intofaces  forced  each 
retrofit  installation  into  a  unique  "Point  Design"  with  no  further  use.  Lack  of  consistent 
interfaces  were  apparent  in  both  hardware  and  software  and  much  of  the  incurred  costs 
were  attributed  to  new  Software  development 

20-3  Recommendations  for  Product  Improvement  Systems 
Engineering 

Based  on  the  findings  of  this  Technology  Review,  avionics  product  improvement 
efi^orts  for  future  systems  will  be  greatly  enhanced  by  instituting  following  System 
Engineering  process  procedures; 

(1)  Adopt  a  family  of  nvionics  architecture  standard  elements  and 
appropriate  interface  standards.  Integrate  these  standards  into  the 
Avionics  Systerjis  Engineering  process  as  preferred  standards.  (Applies 
to  both  liairiware  and  Software). 

The  use  of  conunop  avionics  elements  and  interfaces  will  simply 
retrofits  into  multiple  platforms  since  the  interfaces  will  be  the  same  for 
each. 
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(2)  When  possible,  adopt  Open  System  standards  and  support  the 
maintenance  of  the  stwdards  by  full  government  participation  in  the 
Standards  Groups  that  develop  and  maintain  them. 

Consistent  with  the  use  of  a  common  set  of  interface  standards,  this  will 
ensure  that  the  standards  satisfy  military  avionics  needs  and  are 
supportedby  a  broad  industry  base. 

(3) .  Support  the  concepts  of  modularity  for  both  Hardware  and  Software. 

Reliance  on  Modular  Avionics  provides  a  Systems  Engineering  basis 
that  allows  for  technology  insertion  at  the  Line  Replaceable  Module 
(LRM)  level  that  mitigates  technology  obsolescence  and  provide^  for 
affordable  module  level  system  upgra^g. 

Software  modularity  promotes  the  capability  for  software  reusability, 

.  that  in  turn  will  help  to  control  the  inordinate  software  costs  associated 
with  system  retrofits  and  upgrades. 

(4) .  Emphasize  the  need  to  plan  for  retrofits  and  upgrades  as  part  of  the 

Program  Managers  Systems  Engineering  responsibilities.  This 
planning  should  be  instituted  in  very  early  phases  of  the  Avionics 
system  conceptual  development  to  integrate  the  conc^t  of  iq>grades  and 
P^I  initiatives  into  the  early  Functional  Architecture  d^nitkm. 

System  Upgradeability  should  routinely  be  considered  as  part  of  the 
evaluation  criteria  when  comparing  alternate  architectural  system 
solutions.  In  the  present  period  of  fewer  platforms,  each  performing 
multiple  roles,  planning  for  product  improvements  and  future 
reco^iguration  must  become  embedded  injhe  Systems  Engineering 
process. 
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21-1  GenerM 

Because  of  the  complexity  of  the  Systems  Engineering  efforts  described  above,  it  is 
necessaiyr  that  Systems  En^neering  application  guidance  be  provided.  Whether  in  the  form 
of  application  guidelines  or  a  full  fledged  user's  handbook,  the  guidance  should  not 
duplicate  guidtmce  available  from  other  sources  such  as  MD^-S'IT>-499B  but  should 
interpret  these  documents  for  avionics  and  extend  the  guidance  whoe  necessary. 

Effective  guidance  for  avionics  must  recognize  the  severe  operational  environment 
for  high  poformance  military  aircraft  and  the  added  difficulties  imposed  by  designing  for 
and  qualifying  tp  this  environment.  The  following  sections  provide  specifics  as  to  the 
guidance  to  be  provided  to  the  Program  Manager  rmd  his  staff. 


21-2  Custom  tailoring  of  MIL-STD-499B  for  Avionics/Aircraft 
Development 

As  the  defining  document  for  the  application  of  systems  engmeering  to  the 
development  of  military  systems,  MIL-STD-499B  provides  a  comprehensive  guide  to  the 
systems  engineering  process  applied  to  the  development  of  defense  systems.  As  stated  in 
MD[L-STIM99B,  it  is  important  that  die  document  be  tailored  to  accommodate  the  specific 
nature  and  system  peculiar  needs  for  each  separate  product  class.  A  tailoring  is  necessary 
because  of  spcciAc  needs  and  constraints  necessary  to  satisfy  the  operating  environments 
and  restrictive  supportability  requirements  imposed  by  carrier  operation.  Examples  of  the 
special  requirements  impost  upon  Naval  airc^t  include  the  following; 

•  Severe  vibration,  thennal  and  thermal  shock  (rapid  thermal  cycling), 
characteristic  of  avionics  environments  on  high  peifoimance  aircraft 

•  Stringent  Electro-Magnetic  Interference  (EMI)  shielding  needs  imposed  by 
proximity  to  high  radiation  fields  aboard  aircraft  carriers  (shipboard  Radar, 
etc.). 

•  A  need  for  "Real  Time"  processing  that  is  much  more  stringent  (faster 
processing  times)  than  the  "Real  Time"  needs  for  commercial  applications.  This 
is  especially  demanding  on  software  performance. 

•  The  need  for  multi-level  security  in  an  avionics  suite  predicated  on  shared  b  ises 
and  networks. 

•  Severely  restricted  and  oddly  configured  areas/bays  available  to  install  avionics 
equipment 

•  Supportability  within  an  aircraft  carrier  environment  which  imposes  ctxistraints 
on  configuration  management  (minimizing  the  number  of  different 
configurations),  requires  minimizing  spares  requirements  and  requires 
conformance  to  established  maintenance  procedures. 


These  (and  other  additional)  factors  can  be  dealt  with,  but  do  require  special 
consideration  as  part  of  a  customized  Systems  Engineering  Process  for  Naval  aircraft 
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Tailoring  of  MIL-STD*499B  for  avionics  will  provide  more  direct  guidance 
to  the  avionics  acquisition/devclopment  process  in  terms  of  relevance  to  systems  peculiar 
aspects  of  avionics.  Administered  by  the  NAVAIR  Avionics  division  for  all  Naval 
Avionics  development  programs,  such  a  tailored  document  can  provide  for  higher  level 
standardization  without  uiiduly  limiting  the  capability  of  the  individual  program  nianager  to 
develop  for  high  performance.  Because  of  the  wide  diversity  of  Naval  avionics  aircraft 
platforms,  additipnal  guidance  beyond  the  tailored  standard  is  recommended.  Additional 
guidance  should  be  provided  in  two  forms.  Tlie  first  recommendation  is  that  a  series  of 
templates  be  prepared  for  each  of  the  classes  of  Navy  aircraft  or  aircraft  missions.  For 
example,  one  template  could  be  prepared  for  advanced  high  perform&nce  tactical  aircraft 
with  complex  nussions,  and  a  major  requirement  for  high  speed  processing  and 
interconnection  netwoiics.  A  separate  template  could  be  prepared  for  each  additional  class 
of  aircraft  or  each  functional  set  of  mission  requirements  to  provide  specific  guidance. 


21-3  Cii.^toitiizing  S£  for  Advanced  Integrated  Avionics 

21-3.1  Accommodate  Open  Systems  Trends 

Avionics  application  of  systems  engineering  appropriate  for  the  present  day  must 
accommodate  trends  towards  the  use  of  Open  Systetns  Architectures  (OSA).  Effective 
accommodation  of  the  OSA  approach  requires  that  the  Navy  must  become  knowledgeable 
on  all  the  various  systems  buUding  blocks  that  constitute  advanced  integrated  avionics 
architectures.  These  building  block  elements  consisting  of  busses/networks,  processors  of 
various  types,  memory  devices,  etc.  usually  represent  state-of-the-art  technologies  that  are 
continually  changing.  It  is  important  that  Navy  technologists  are  brought  into  the  avionics 
development  process  in  the  earliest  phases  of  system  development  so  that  advanced  tech¬ 
nologies  can  be  effectively  evaluated  for  maturity,  value  added  and  realistic  risk 
assessment. 

Important  features  of  the  OSA  concept  must  be  accommodated  by  the  Systems 
Engineering  procei^  s  employed.  When  the  choice  is  available,  emphasis  should  be  placed 
on  the  use  of  non-proprietary  interface  standards  or  at  least  attempt  to  make  the  standards 
chosen  available  as  “open”  or  non-proprietary  standards.  The  use  of  COTS  should  be 
acconomodaied  so  that  leverage  of  the  commercial  market  place  can  be  achieved  when 
feasible.  Agreement  reached  during  the  review  was  to  use  the  SE  process  to  consider 
COTS  standards  and  products  aiong  with  products  designed  specifically  for  the  military 
market  in  a  strictly  objective  franoe  of  reference.  This  approach  allows  the  use  of  COTS  to 
be  considered  on  a  case  by  case  basis  to  achieve  the  best  “value”  for  the  system 
development  To  use  this  approach  effectively,  guidelines  for  the  evaluation  of  COTS  must 
be  established  to  assure  that  the  cost  and  development  time  to  add  special  features  to  COTS 
to  sustain  performance  in  a  more  severe  environment  (technically  tiiis  is  now  called 
militarized  COTS),  and  the  cost  of  adding  additional  configuration  data  (if  necessary),  etc., 
are  traded  off  against  cost  advantages  afforded  by  the  COl^. 


21-3.2  Linking  of  COTS  and  Open  Systems  Architecture. 

COTS  and  Open  Systems  are  often  thought  of  together.  It  is  not  necessarily  true 
tiiat  COTS  products  are  based  on  Open  System  standards.  Many  of  the  available  COTS 
products  are  as  often  point  designs  as  are  military  products,  in  selecting  COTS  for  a 
pervasive  role,  it  is  important  Aat  the  necessary  interface  standards  arc  "open",  non- 
proprietary  and  well  defined/disclosed.  Certainly  the  most  effective  way  to  ensure  effective 
use  of  COTS  standards  and  products  by  the  military  is  for  joint  standardization,  and  full 
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participation  (by  commercial  industry  and  the  military)  in  the  development  and  review  of 
the  underlying  standards. 


21-3.3  Modular  Avionics  for  Growth  and  Ability  to  Upgrade 

The  architectures  chosen  for  advanced  high  performance  integrated  avionics 
systems  must  be  well  defined  and  suitable  for  the  growth  and  evolution  necessary  to  match 
the  growth  needs  required  of  increasingly  complex  upgradable  systems  for  advanced 
avionics.  The  Systems  Engineering  process  employed  must  require  that  provision  for 
growth  and  ability  to  upgrade  are  considered  to  be  fundamental  parameters.  Sizing  of 
processors,  memory  and  busses/networks  is  a  key  to  this  planning.  The  avionics  systems 
envisiemed  place  considerable  emphasis  on  the  use  of  noodular  paclragcd  avionics.  Modular 
packaging  has  become  the  preferred  approach,  where  practical,  tecause  it  provides  for 
effective  use  of  high  density  microelectronics,  employs  effective  cooling  techniques  and 
provides  for  high  speed  data  transfer  on  the  backplane  by  means  of  data  paths  and  data 
buses.  The  Navy  SHARP  program  has  dealt  with  advanced  modular  paclraging  for  both 
air  and  ship  platforms.  The  NAVAIR  directed  Advanced  Avionics  Technology 
Demonstration  (AATD)  program  has  funded  advanced  avionics  packaging  research  often 
jointly  funding  efforts  with  the  SHARP  program  It  is  recommended  that  close  coordination 
be  maintain^  between  avionics  systems  engineering  decisions  and  the  focus  of 
SHARP/AATD  avionics  packaging  research  so  that  the  research  is  well  focused  and 
coordinated  with  the  specific  development  guidelines  utilized  by  the  Program  Manager. 

21-3.4  Process  Integration  of  Hardware  and  Software  Development 

Of  necessity,  the  development  of  software  has  closely  focused  on  process.  Ths 
software  development  process  has  initiated  numy  computer  aided  tool  developments  with 
the  result  that  an  entire  category  of  computer  based  tools  are  called  Computer  Aided 
Software  Engineering  (CASE)  tools.  The  SE  process  requires  that  the  development  of 
Software  be  integrated  effectively  with  Hardware  development  for  efficiency.  The 
Software  Development  process  should  be  considered  only  a  component  of  the  entire 
systems  engineering  process.  Many  case  tool  developers  now  focus  on  the  entire  systems 
engineering  process  with  the  result  that  the  use  of  CASE  often  is  used  to  mean  Computer 
Aided  Systems  Engineering  as  well.  Navy  tailoring  of  the  SE  process  for  avionics  should 
have  as  a  goal  more  effective  integration  of  the  hardware  and  software  development 
processes.  It  is  important  to  think  of  Software  engineering  as  part  of  an  integrated  S;^tmns 
Engineering  process,  not  as  a  separate  discipline. 

21-3.5  Employ  Multi-Disciplinary  Product  Teams 
The  Systems  Engineering  Process  management  approach  that  best  meets  the  DODI 50002 
requirement  for  organizing  for  efficiency  and  effectiveness  utilizes  the  integrated  product 
team,  or  a  nudti-disciplinary  effort  to  ensure  a  lanced  approach  to  development. 

Organize  functionally  within  the  Navy  (specifically  within  NAVAIR)  to  encourage  Multi- 
Disciplin^  product  teams  for  avionics  acquisition.  Organizing  government  acquisition 
for  avionics  along  the  lines  of  the  technical  disciplines  employed  in  modem  avionics 
systems  provides  die  basis  for  a  multi-disciplinary  product  team  organization  for  avionics 
i^uisition  that  parallels  the  teams  used  by  indust^  for  development  Providing  training  to 
Navy  avionics  acquisition  personnel  in  team  dynamics  and  methods  will  develop  skills  that 
will  make  the  working  of  government  IPTs  effective  and  provide  an  a  better  understanding 
of  the  workings  of  industry  IPTs. 
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Encourage  contractors  to  use,  multi-disciplinary  Integrated  Product  Teams  (IFTs) 
for  development.  Establish  modifications  to  FAR/DAR,  as  necessary,  that  allow  for 
effective  government  representation  to  contractor  IPTs  when  appropriate. 
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22-0  SYSTEMS  ENGINEERING  STANDARDIZATION 


22-1  General 

Characteristic  of  the  revitalization  of  Systems  Engineering  is  a  parallel  focus  on 
definition  and  standardization  of  methodology,  processes  and  tools  used  in  its  application. 
Generic  Systems  En^neering  is  practiced  in  both  commercial  and  military  sectors,  often 
with  different  constraints  but  with  essentially  the  sanne  process  elements.  A  certain  lack  of 
generally  agreed  upon  derinitions  of  Systems  Engineering  and  the  technical  boundaries 
within  which  it  is  applied  is  most  likely  due  to  the  fact  that  it  has  only  become  a  generally 
recognized  engineering  discipline  in  recent  years.  With  recognition  comes  standi^zation 
activities  to  formally  define  Systems  Engineering  standards  and  practice.  In  this  section, 
some  standardization  activities  useful  to  Navy  avionics  are  discuss*^ 


22-2  Deft^nse  Systems  Management  College 

The  Defense  Systems  Management  College  (DSMC)  serves  as  the  national  center  of 
excellence  for  defense  acquisition  management  education,  research,  consulting  and 
generation  of  supporting  publications.  The  DSMC  Systems  l^gineering  Department  has 
long  led  the  way  in  defining  Systems  Engineering  as  applied  to  the  Systems  Life  Cycle. 
DSMC  initially  published  a  “Systems  Engineering  Management  Guide  “  in  October  1983. 
This  Guide  succeeded  by  revisions  in  October  1986  and  most  recently  Decembeu*  1989 
serve  as  the  definitive  DoD  reference  to  Systems  Engineering  application.  More  lecentiy 
the  DSMC  Systems  Engineering  faculty  have  taken  the  lead  in  the  preparation  of  MO^STD- 
499B,  "Systems  Engineering"  (draft  dated  May  1992),  the  defining  standard  for  the 
application  of  Systems  Engineering  to  DoD  Systems  acquisition.  Ihe  faculty  of  the 
Systems  Engineering  Department  is  very  much  in  the  forefront  of  modem  Systems 
Engineering  practice  and  can  serves  as  a  prime  consultant  to  the  Naval  Air  Systems 
Command  for  implementation  of  a  rigorous  Systems  Engineering  basis  for  avionics 
acquisition. 


22-3  Nation<\l  Council  of  Systems  Engineering 

The  National  Council  of  Systems  Engineering  (NCOSE),  was  founded  in 
recognition  of  the  increasingly  important  role  of  good  Systems  Engineering  practice  to 
industrial  productivity  in  the  United  States.  Its  founders  recognized  the  need  for  a  forum  to 
exchange  information  regarding  Systems  Engineering  and  to  establish  standards  for  its 
practice.  Established  in  late  19%,  NCXDSE  has  experienced  very  rapid  growth  with  over 
1S(X)  members  registered  by  mid  1993. 

The  rapid  growth  of  NCOSE  reflects  an  emphasis  within  US  industry  on  methods 
to  increase  productivity  and  the  role  that  Systems  Engineering  plays  in  productivity 
enhancement.  NCOSE  serves  both  the  commercial  and  i^itary  arenas.  With  Dr.  Jerome 
(Jerry)  Lake  of  the  Systems  Engineering  Department  at  DSMC  serving  as  the  Erst  national 
president,  NCOSE  activities  initially  cento^  on  the  review  and  revision  of  MIL-STD- 
499B.  With  NCOSE  involved  in  its  review,  the  DoD  is  assured  that  the  standard  is 
consistent  with  generic  systems  engineering  practice,  and  DoD  needs  for  the  System 
Engineering  Process  are  carried  over  to  commercial  practice  through  the  membership. 
Interest  in  NCOSE  has  extended  to  the  international  community,  with  a  recent 
recommendation  to  change  the  name  from  "National"  to  "International"  Council  on  Systems 
Engineering.  There  are  now  twelve  local  chapters  including  Boston  MA,  Houston  TX, 
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Huntsville  AL„Melboume  FL,  San  Bernardino,  CA,  San  Francisco,  CA,  St.  Louis  MO, 
Whippany  NJ,  Seattle  WA  and  Washington,  DC.,  with  at  least  eight  other  localities 
currently  applying  for  official  chapter  stams. 

Corporate  membership  includes.  Aerospace  Coiporation,  Ascent  Logic,  Grumman, 
GTE,  Hughes,  CBM,  Lockheed,  Martin  Marietta,  Mitre,  Motorola,  and  Northrop. 

Presently,  the  Systems  Engineering  Practices  Committee  has  a  number  of  active 
Subcommittees  serving  as  technical  working  groups.  Current  Subcommittees  include: 

(1)  Concurrent  Engineering 

(2)  Metrics 

(3)  Risk  Management 

(4)  Requirements  Management 

(5)  Principles  of  SE 

(6)  Policy  Review 

0)  Tools 

(8)  Process  Description,  and 

(9)  Best  Practices 

Each  of  these  groups  is  working  towards  agreement  on  standards  for  practice 
within  each  specific  Systems  Engineering  specialty  area  identified. 


22-4  Standards  for  Systems  Engineering  Education 

Develop  focused  training  programs  for  all  applicable  management  and  technical 
levels.  The  entire  area  of  training  is  complex  and  should  be  integrated  into  an  overall 
training  plan.  SE  training  should  provide  a  customized  curriculum  emphasizing  avionics 
systems  and  avionics  issues  as  examples  and  case  studies. 

SE  training  should  also  emphasize  the  integration  of  all  engineering  disciplines, 
such  as  software  engineering  and  supportability  engineering  under  the  SE  umbrella. 
Training  in  the  use  of  Open  Systems  standards  and  COTS  should  be  provided, 
emphasiring  selecdon  guidelines. 

Coordinate  training  with  specifics  of  MIL-STD-499B,  the  Standard  for  Systems 
Engineering.  Coordinate  with  the  Systems  Engineering  Department  at  DSMC.  Utiuze  the 
National  Council  on  Systems  Engineering  (NCOSE)  as  a  systems  engineering  forum. 
Since  the  NCOSE  has  a  wide  diversity  in  membership  and  application  point  of  view,  it 
provides  a  forum  for  reviewing  systems  engineering  concept  techniques  and  tools  that  are 
introduced  an  used  throughout  the  commercial  sector  of  industry  as  well  as  in  government 
As  a  result,  systems  engineering  concepts  and  supporting  tools  developed  for  the 
Commercial  Off  The  Shelf  (COTS)  community  are  offered  as  well.  Participation  in 
NCOSE  will  therefore  afford  the  military  an  opportunity  to  evaluate  and  leverage 
cmnmercial  systems  engineering  approaches  for  application  to  military  applications. 

Additionally,  the  NCOSE  is  currently  reviewing  the  preparation  of  accredited 
systems  engineering  curricula.  The  curricula  is  being  developed  by  recognized  academic 
leaders  in  the  field  of  systems  engineering  in  coordination  with  experienced  pi^tioncrs  in 
both  industry  and  in  the  government,  As  a  recognized  and  accredited  engineering  specialty. 
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the  future  Navy  can  expect  to  acquire  engineers  holding  degrees  and  expert  in  the  technical 
disciplines  that  are  embodied  in  systems  engineenng. 

To  leverage  this  effort,  the  Navy  should  consider  developing  an  accredited  systems 
engineering  curriculum  as  an  avionics/aerospace  specialty.  This  could  be  done  in 
coonlination  with  the  NCOSE,  together  with  the  Systems  Engineering  Department  at 
DSMC,  if  desired.  An  available,  accredited  professional  avionics  systems  engineering 
degree  program  at  the  Masters  Degree  level  could  be  integrated  into  the.  Navy  training 
program  (at  NAVAIR  and  at  supporting  NAWC  facilities)  through  supporting  local 
universities.  This  approach  could  provide  a  knowledgeable  corps  of  systems  engmeers 
experienced  in  the  application  of  SE  principles  to  the  development  and  acquisition  of 
advanced  avionics  systems. 


22-5  The  Role  of  the  Society  of  Automotive  Engineers  (SAE) 
Avionics  Systems  Division 

The  SAE  has  long  served  the  needs  of  the  Aerospace  community  tl^ugh  activities 
of  it's  Aircraft  Engineering  Divisions  under  the  SAE  Aerospace  Council.  Particularly 
appropriate  to  DoD  avionics  standardization  is  the  SAE  Avionics  Systems  Division  (ASD). 
ASD  along  with  its  jpredecessor  SAE  organization  has  logged  m^  that  twenty  five  years 
of  service  to  DoD  m  providing  avionics  standardization.  Beginning  with  the  standard 
avionics  data  bus.  which  became  MIL-STD‘1553.  a  prime  integrating  tool  for  modem 
avionics,  the  SAE  ASD  has  oversight  over  MIL-STD-1760,  The  Stores  Interface 
Standard,  and  MIL-STD-1750  for  Standard  Military  Microprocessors.  The  SAE  led  the 
way  in  developing  a  concept  for  high  speed  data  bus  systems  (HSDB)  for  notary  aircraft 
The  SAE  Standa^  for  a  Linear  Token  Passing  HSDB  Protocol  is  the  basis  for  50  Mb/S 
buses  employed  in  the  F-22  and  RAH-66  aircraft. 

The  SAE  ASD  has  a  broad  international  membership  of  leading  aerospace  and 
avionics  systems  developers  and  system  integrators  as  well  as  component  manufacturers. 
It  has  a  broad  representation  from  all  U.S.  military  services  and  forms  a  ^ad 
standardization  oig^anization  suitable  for  dealing  with  the  overall  issues  of  military  avionics 
standardization. 
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23-0  IMPLEMENTATION  STRATEGIES  AND  PLANS 


General  Approach 

In  preparing  beginnings  of  an  implementation  plan  to  utilize  the  findings  of  this 
review,  the  following  ideas  become  clear.  The  key  finding  or  "backbone"  for 
implementation  is  the  rigorous  use  of  Systems  Engineering,  customized  as  required  for 
avionics  systems.  The  principal  focus  of  our  avionics  development  of  necessity  is  now 
Affordability,  or  more  appropriately  a  quality,  supportable  product  that  is  also  affordable. 
A  Systems  l^gineering  basis  becomes  the  "backbone"  for  a  process  that  leads  us  to  high 
performance  high  quality  affordable  avionics. 


23-1  Apply  Open  System  Standards  through  the  SE  Process 

The  other  key  findings  then  become  modifiers  to  the  S£  process.  Endorsing  an 
Open  System  Architectural  approach  based  on  Open  Interface  Standards  allows  us  to  move 
into  the  mainstream  of  non-proprietary  standardization.  Much  current  standardization  is  in 
the  Open  System  arena  is  concerned  with  Computer^etwork  standard  based  on  the 
International  Standards  Organization  (ISO)  model  for  computer  communications  called  die 
Open  System  Interconnect  (OSI)  mo^l.  The  advantage  of  using  Open  Standards  where 
suitable,  is  that  these  standard  be  well  supported  by  the  commer^  industry  sector  as 
well  as  Ae  DoD  industty  sector  with  suitable  ir^taiy  endorsement.  This  should  provide  us 
with  a  broader  industri^  base  to  support  our  systems  applications.  C^en  systems  should 
provide  forportability  of  software  and  overall  scalability;  both  features  that  will  aid  in 
obtaining  affordable  avionics  products. 
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Figure  23-1  illustrates  the  central  role  that  can  be  played  by  the  Systems 
Engineering  Process  in  establishing  a  complement  of  effective  system  standards. 

Within  the  figure  the  SEP  is  represented  as  a  functional  Block  with  inputs  received 
as  system  requirements  and  as  constraints  to  the  process.  For  avionics  systems  it  is 
understood  that  the  SEP  Block  is  customized  for  the  specific  needs  of  avionics  systems  and 
is  to  be  in  harmony  with  the  current  avionics  development  process  (e.g.  customized  to 
work  vrith  cunent  avionics  technologies,  development  tools  and  manufacturing  processes). 
Through  application  of  the  process,  standards  that  represent  architectu^  elements 
(architecturid  components)  and  standard  interfaces  are  udlized  to  conceive  candidate 
architectural  solutions.  Suitable  Open  System  standards  can  be  utilized  as  elements  or 
"candidate  pieces"  of  architectural  soludons.  As  standards  are  utilized  in  developmental 
avionics  architectures  they  acquire  an  applicadon  histoiy  and,  if  successful,  are  candidates 
for  the  preferred  avionics  standard*'  list  Although  explicit  avionics  requirements  vary  with 
the  specific  needs  and  constraints  of  each  program,  it  is  expected  that  a  core  set  of 
standards  will  emerge  to  provide  some  overall  standardizadon  and  consistency  to  future 
Navy  avionics.  If  the  system  requirements  analysis  is  rigorously  performed  to  ensure  that 
die  system  development  requirements  arc  well  defmed  and  clearly  match  the  system's 
perfoimance  needs,  applicadon  of  the  SEP  will  ensure  the  availability  of  an  optim^  set  of 
prefened  standards.  Addidonally  this  process  allows  the  architecture  to  evolve  with 
technolo^  advances.  As  standards  that  reflect  new  technologies  are  prepared  they  can  be 
infused  into  the  preferred  standards  set  through  the  same  SEP  p^ess  as  a  need  is 
demonstrated. 


23 >2  Promote  a  Rational  Use  of  COTS/NDI  Under  SE  Guidelines 

Emphasis  on  COTS  and  NDI  products  is  also  a  DoD  endorsed  inidadve  dtat  should 
aid  in  ovei^l  affordability.  In  leveraging  the  commercial  industry  we  are  leveraging  a 
bro.’ui  sector  of  the  industrial  base  for  our  applicadons.  The  same  SEP  approach  shown  in 
FigJite  23-1.  is  applicable  for  consideradon  of  COTS  and  NDI  products  as  well.  By 
undergoing  the  same  SEP  corsideradons  as  are  applied  to  "designed  for  military  use" 
products,  COTS  and  NDI  products  can  be  consider^  for  avionics  architecture  designs. 
The  responsibility  placed  on  the  SEP  is  to  ensure  that  the  selecdon  criteria  for  COTS/NDI  is 
as  rigorous  as  for  military  products  so  that  it's  use  provides  a  "real"  net  gain  in  overall 
affoidaUlity  without  significant  losses  in  peifonramce.  Where  the  COTS/NDI  products  are 
designed  to  Open  Systems  standards,  those  stanchuds  become  candidates  for  Ae  preferred 
standards  set 

At  another  level  it  is  important  that  we  support  the  value  of  joint  standardizadon 
efforts  among  the  military  services.  Leveraging  COTS  and  Open  System  standards  for 
military  avionics  enhances  the  affordability  for  our  avionics.  Leveraging  COTS  and  Open 
System  standards  on  a  joint  service  basis  expands  the  potential  scale  for  COTS/Open 
Systems  based  products  applicadon  to  the  milit^  avionics  maricet  To  make  this  ^pprx^h 
work  effectively,  the  Joint  Services  must  adopt  generally  the  same  SE  basis  for  avionics 
applicadon  and  sinoilar  strategies  for  the  use  of  O^n  System  standards  and  COTS. 
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24-0  SYSTEMS  ENGINEERING  SUMMARY 

Systems  Engineering  is  precise  and  rigorous.  Its  elements  have  been  well  dcfuied 
and  its  proper  mode  of  application  is  well  known.  Policy  defines  the  need  and  puts  in  place 
the  requirement  to  fully  utilize  Systems  Engineering  in  weapon  systems  engineering.  The 
Systems  Engineering  ftocess  is  well  integrated  into  the  acquisition  life  cycle  in  all  phases. 
If  the  process  is  in  place  and  its  value  is  unquestioned,  then  why  do  we  have  problems  in 
efficiently  and  effectively  developing  complex  avionics  systems  ? 

The  simple  answer  is  because  we  haven't  yet  become  consistent  and  fully  proficient 
in  applying  the  Systems  Engineering  Process.  There  are  a  number  of  reasons  for  this 
situation.  First  and  foremost,  the  complexity  of  the  systems  engineering  process  demands 
a  great  deal  of  exjwricncc  and  senior  leadership.  No  one  will  be  expert  their  first  time 
through.  Secondly  from  the  top  (the  Program  Manager),  down  tlmough  the  ranks,  Ae 
teams  put  together  on  the  government  side  arc  often  spread  thin  with  respect  to  applied 
development  experience.  An  additional  factor  is  often  a  lack  of  a  sophisticated  knowledge 
of  the  advanced  technologies  applied  to  advanced  avionics.  To  some  extent,  we  have  left 
our  technological  roots  behind  in  pursuit  of  managerial  excellence.  A  knowledge  of  the 
technology  is  still  critical  to  the  acquisition  of  sophisticated  avionics,  which  remains  heavily 
dependent  on  the  application  of  advanced  technologies. 

The  evolving  trend  toward  the  use  of  Integrated  Product  Teams  is  relatively  new 
and  is  not  fully  in  place  in  the  Navy  Aviation  Team.  A  problem  with  the  use  of  EPTs  is  that 
it  represents  a  major  culture  change  for  acquisition.  Significant  training  is  necessary  before 
integrated  team  approaches  can  be  used  effectively.  The  IPT  concept  also  suffers  fiom 
.sparse  staffing  of  programs.  The  Program  Manager  must  make  up  for  his  lack  of  full 
headquarters  staffing  by  ever  increasing  reliance  on  field  activity  and  contract  supj^rt 
personnel.  The  Field  Activities  to  some  extent  suffer  the  same  depletion  of  technical 
personnel  from  their  ranks  as  does  the  PM  Ofifice. 

In  addition  to  the  above,  the  Systems  Engineering  Process  is  being  redefined.  As  a 
recently  recognized  engineering  discipline,  it  is  still  undergoing  ^finition  and  change.  The 
structure  for  rigorous  application  is  not  yet  ctmsistently  in  place  in  either  industry  and  DoD. 
The  recent  revision  of  the  Systems  Engineering  Standaid,  MI^STD-499B,  provides  a 
modem  basis  for  practice,  but  is  not  yet  formally  approved.  It  is  important  to  recogr^  the 
full  impact  of  this  revised  standard.  Since  the  release  of  the  ^sent  draft  standard- in  May 
1992,  it  has  served  as  a  catalyst  for  renewed  activity  in  the  practice  of  Systems 
Engineering.  The  Air  Force  has  started  the  development  of  a  series  of  five  handb^ks  to 
support  the  revised  process.  Industry  has  enthusiastically  endorsed  the  document  and 
urges  that  it  be  officially  released  as  soon  as  possible.  The  National  Ck>uncil  on  Systems 
Engineering  (NCOSE)  participated  in  the  preparation  and  review  of  the  document  and  have 
us^  it  as  a  structural  reference  for  the  organization  of  NCOSE  and  to  develop  focus  areas 
for  standardization.  As  a  result  many  industrial  concerns  have  been  actively  engaged  in  the 
review  and  revision  of  their  own  Systems  Engineering  Process  to  accommodate  the 
revisions  in  the  process.  Techniques  advocated  in  MIL-STD-499B,  including  the  use  of  an 
engineering  WBS  to  structure  the  process  and  provide  a  basis  for,  interdisciplinary  product 
teams,  and  the  use  of  incremental  technical  reviews  for  more  effective  process  control  are 
new  a^  will  take  some  time  to  fully  integrate  into  the  acquisition  process. 

Moreover,  the  computer  tools  that  directly  assist  the  Systems  En^necring  Process 
have  not  been  readily  available.  These  tools  are  now  rapidly  advancing  in  capability  imd 
arc  now  being  focused  directly  on  specific  Systems  Engineering  tasks.  It  is  now  possible 
to  select  a  Systems  l^gineering  tool  set  tliat  supports  the  acquisition  process  from  concept 
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through  development  and  deployment  Tnc  problem  with  Systems  Engineering  tools  is  that 
they  are  costly  and  not  yet  integrated  as  a  full  set.  However  this  situation  is  rapidly 
changing  as  the  tools  are  maturing  and  interfaces  are  being  constructed  to  effectively 
interface  many  of  the  most  popular  tools  to  each  other. 

In  short,  there  is  no  single  simple  answer  to  a  lack  of  consistent  application  of 
Systems  Engineering  to  avionics  development.  Putting  in  place  and  emphasizinp  the  use 
of  a  development  process  that  makes  effective  use  of  Systems  Engineering  principles  and 
tools  for  advanced  avionics  systems  is  an  important  step  towards  satisfying  a  demonstrated 
need. 
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APPENDIX  A 

SYSTEMS  ENGINEERING  GLOSSARY 

1.0  Definition  of  Tenns  Commonly  Encountered  in  Systems  Engineering 

Acquisition  Decision  Memorandum  (ADM).  A  memorandum  signed  by  the 
nulestone  dedsion  authority  that  documents  decisions  made  and  the  exit 
criteria  established  as  the  result  of  a  milestone  decision  review  or  in-process 
review. 

Acquisition  Process.  The  process  of  bringing  a  system  into  being.  This 
includes  the  phases  of  conceptual  design  and  advance  planning,  preliminary 
system  design  (demonstration  and  validation),  detail  design  and 
development  (full  scale  development),  and  production  and/or  construction. 
Given  a  defined  need,  the  process  includes  diose  steps  leading  from  the 
requirements  definition  stage  to  the  delivery  of  the  system  for  use. 

Allocation.  The  top-down  distribution,  or  apportiozunent,  of  system-  level 
requirements  to  the  subsystem,  equipment,  software,  imit,  or  below,  to  the 
depth  necessary  for  providing  criteria  as  an  input  to  design.  This  process  tends 
to  promote  a  top-down  "systems  approach"  in  helping  to  establish  specific 
design  requirements  for  all  levels  of  the  system  hierarchy  as  appropriate. 

Allocated  Baseline.  The  initially  approved  documentation  describing  a 
Configuration  Item's  (Cl)  functional,  performance,  interoperability,  and 
interface  requirements  that  are  allocated  from  those  of  the  system  or  a  higher 
level  Cl;  interface  requirements  with  interfacing  CIs;  design  constraints; 
derived  requirements  (functional  and  performance);  and  verification 
requirements  and  methods  to  demonstrate  the  achievement  of  those 
requirements  and  constraints.  The  allocated  baseline  is  typically  placed  under 
Government  control  during  Engineering  and  Management  Development. 
There  is  an  allocated  baseline  for  each  CL 

Assemble.  The  physical  act  of  putting  the  document  or  description  together 
using  the  inputs  of  all  appropriate  supporting  disciplines.  To  be  the  focal 
point  of  the  activity  and  to  be  responsible  for  the  quality  and  coherency  of  the 
output. 


Authentication.  An  act  by  the  Government  that  results  in  the  Government 
approving  and  taking  control  of  a  configuration  baseline. 
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Computer-aided  Acquisition  And  Logistic  Support  (CALS)  The  application  of 
computerized  technology  and  available  computer  software  to  the  entire 
spectrum  of  logistics.  This  includes  the  use  of  computer  methodsVtools  in  the 
design  for  system  supportability  (integrated  into  C  ASE/CAE/CAD  activities), 
in  the  development  of  logistic  support  analysis  data  in  determining  logistic 
resource  requirements,  in  the  provisioning  and  acquisition  of  the  identified 
elements  of  support  (e.g.,  spare/ repair  parts,  test  and  support  equipment),  and 
in  the  assessment  of  the  system  support  capability  in  the  user's  environment. 
CALS  also  includes  the  development  of  technical  manuals  and  the  processing 
of  design  data  automatically  and  using  a  digital  data  format. 

Computer-Aided  Design  (CAD).  The  process  of  utilizing  computer 
capabilities  and  available  software  to  support  detailed  engineering  design 
activities.  CAD  tends  to  deal  primarily  with  three-dimensional  graphics, 
circuit  board  layouts,  the  accomplishment  of  various  categories  of  analyses, 
and  the  like. 

Computer-Aided  Engineering  (CAE)  .  The  process  of  utilizing  computo 
capabilities  and  available  software  to  support  engineering  design;  activities. 
CAE  tends  to  deal  primarily  with  engineering  analyses  and  lower-level  design 
activity,  similar  to  the  fvmctions  of  CAD. 

Computer-Aided  Manufacturing  (CAM).  The  process  of  utilizing  computer 
capabilities,  available  software,  numerical  control  equipment,  robotics,  and 
related  resources  to  manufacture  and  produce  producte  through  automated 
means.  CAM  tends  to  deal  with  production  process  planning,  materials 
handling,  numufacturing,  inventory  control,  and  production  management. 

Computer-Aided  Systems  Engineering  (CASE).  The  process  of  integrating 
system  engineering  concepts  and  constructs,  computer  capabilities,  the  use  of 
analylical  nietliods,  and  available  software  in  sudt  a  manner  as  to  complete 
system  engineering  functions  in  an  effective  and  efficient  manner.  CASE 
represents  a  broader  level  of  capability  than  either  CAD  or  CAE. 

Computer-Integrated  Manufacturing  (CIM).  The  process  of  utilizing 
computer  capabilities  and  available  software  to  manufacture  products  via 
automated  means.  CIM  is  used  in  a  mannar  similar  to  CAM,  except  that  CUM 
tends  to  emphasize  the  use  of  microcomputers  and  a  conunon  database. 
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Concurrent  Engineering.  "A  systematic  approach  to  the  integrated, 
concurrent  design  of  products  and  their  related  processes,  including 
manufactiire  and  support.  This  approach  is  intended  to  cause  the  developers, 
from  the  outset,  to  consider  all  elements  of  the  product ,  life  cycle  from 
conception '  through  disposal,  including  quality,  cost,  schedule,  and  user 
requirements." 

Coordinate.  The  act  of  harmonizing  an  approach  or  the  activities  associated 
with  generating  a  document  or  performing  a  task. 

Configuration  Baselines.  Designated  points  in  the  system  design  and 
development  process  where  the  system  configuration  is  defin<^  in  detail. 
Common  points  include  the  (1)  Functional  Baseline,  where  the  system 
configuration  is  described  through  the  definition  of  operational  requirements 
and  the  maintenance  concept,  the  System  Type  "A"  Specification,  and 
feasibility  study  reports;  (2)  Allocate  Baseline,  where  the  system 
configuration  is  defined  through  a  combination  of  Development,  Process, 
Product,  and  Material  Specifications  (Types  "B,"  "C,"  "D,"  and  "E"),  selected 
design  tradeoff  study  reports,  and  system/subsystem  design  data;  and  (3) 
Product  Baseline,  where  the  system  configuration  is  defined  through  a 
combmation  of  Process,  Product,  and  Material  Specifications  (Types  "C,"  "D," 
and  "E"),  trade-off  study  reports,  detailed  design  data  (drawings,  parts  lists), 
supplier  data,  and  the  like. 

Configuration  Control.  Deals  with  the  categorization  and  control  of 
proposed  design  changes,  that  is,  Class  1  Changes  tliat  affect  form,  fit,  and/or 
function,  and  Class  2  Changes  that  are  relatively  minor  in  nature.  Given  a 
designated  configuration  baseline,  all  changes  applied  to  that  baseline  must  be 
closely  evaluated  and  controlled. 

Configuration  Control  Board  (CCB).  A  board,  consisting  of  expertise 
representing  different  design  disciplines,  responsible  for  the  reviewing  and 
approving  of  changes  to  a  given  configuration  baseline. 

Configuration  Item  (CD.  An  aggregation  of  hardware,  firmware,  or  computer 
software  or  any  of  their  discrete  portions,  which  satisfies  an  end  use  function 
and  is  designated  by  the  Government  for  separate  configuration 
management.  Configuration  items  may  vary  widely  in  complexity,  size  and 
type,  fiom  an  aircraft,  electronic,  or  ship  system.  Any  item  required  for  logistic 
support  and  designated  for  separate  procurement  is  a  configuration  item. 
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Confipiration  Management  iCM).  A  management  process  used  to  identify 
the  functional  and  physical  characteristics  of  an  item  in  the  early  phases  of  its 
life  cyde^  control  changes  to  those  characteristics^  and  record  and  report 
change  processing  and  implementation  status.  CM  involves  four  functions  to 
indude  (1)  configuration  identification,  (2)  configuration  control,  (3) 
conHguration  status  accounting,  and  (4)  configuration  audits.  CM  is  the 
concqpt  of  'baseline"  management. 

Contract  Structure.  The  type  of  contract  negotiated  between  the  customer  and 
the  contractor,  and/or  between  the  contractor  and  the  supplier.  Major 
categories  of  contracts  indude  Firm-Fixed-Price  (FFP),  Fixed-Price-with- 
Escalation,  Fixed-Price-Incentive,  Cost-Plus-Fixed-Fee  (CPFF),  cost-plus- 
Incentive-Fee  (CPIF),  Cost-Sharing,  Time  and  Materials,  and  Letter 
Agreement.  The  nature  and  type  of  contract  negotiated  are  major 
considerations  in  the  implementation  of  system  engineering  requirements. 

Control  Hierarchy  Analysis.  A  functional  analysis  to  determine  if  any 
constraints  should  be  applied  to  the  systems  functional  design  and  how  those 
constraints  will  affect  the  design  implementation. 

Cost  Breakdown  Structure  (CBSL  A  breakdown  of  cost  in  functional  terms. 

All  futtu-e  costs  assodated  with  activities  throughout  all  phases  of  the  system 
life  cyde  must  be  induded,  and  costs  must  be  broken  out  to  the  depth 
required  to  provide  the  necessary  visibility  relative  to  different  elements  of 
the  system  and/or  different  program  activities. 

Cost  Effectiveness  (CE).  The  measure  of  a  system  in  terms  of  its  tedmical 
characteristics  and  life-cyde  cost.  Technical  rharacteristics  may  indude  a 
combination  of  performance,  capadty,  range,  weight  and  size,  reliability, 
maintainability,  supportability,  produdbility,  quality,  and  related  parameters. 
Life-cycle  cost  may  indude  all  future  costs  assodated  with  research,  design 
and  development,  production  and/or  construction,  distribution,  system 
utilization,  sustaining  maintenance  and  support,  retirement,  disposal,  and 
the  recyding  of  materials  as  necessary.  These  technical  characteristics  may  be 
combined  in  some  manner  to  provide  a  measure  of  "System  Effectiveness." 
Cost  E^ectiveness  can  be  expressed  as  the  ratio  of  System  Effectiveness  to  Life- 
Cyde  Cost  (LCC). 

Cost  and  Operational  Effectiveness  Analysis  (COEA).  An  analysis  of  the 
estimated  costs  and  operational  effectiveness  of  alternative  materiel  systems 
to  meet  a  mission  need  and  the  assodated  program  for  acquiring  each 
alternative. 
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Define.  To  be  responsible  for  specifying  an  approach  for  accomplishing  a 
designated  task,  or  the  design  implementation  to  solve  a  given  problem. 

Derived  Requirements.  Those  characteristics  of  a  system  that  are  not  Cixpressly 
specified  by  the  Government,  but  are  necessary  to  have  system  elements 
accomplish  their  intended  functions. 

Design  Review.  A  formal  review  of  the  system  configuration  as  it  is  defined 
at  a  specific  point  in  time.  Formal  design  reviews  mdude  the  Conceptual 
Design  Review,  one  or  more  System  (Preliminary)  Design  Reviews,  one  or 
more  Equipment/Softv/are  Design  Reviews,  arid  a  Criti^  Design  Review. 
Formal  design  reviews  include  the  "checks  and  balances"  necessary  in  the 
implementation  of  system  engineering  functions. 

Design-To-Cost  (PTC).  A  quantitative  "design  to"  figure-of-merit  specified  as 
a  system  requirement  during  conceptual  design  and  included  in  the  System 
Type  "A"  Specification.  The  DTC  figure-of-merit  should  be  specified  in  terms 
of  life-cycle  cost.  This  can,  in  turn,  be  broken  down  into  'T>esign  to  Unit 
Acquisition  Cost"  and  'Design  to  Unit  Operation  and  Support  Cost"  (or 
something  equivalent).  The  basic  categories  of  cost  should  be  defined  in  terms 
of  what  is  (or  is  not)  included. 

Develop.  To  be  responsible  for  the  progression  of  a  concept  or  document  into 
an  end  product. 

Earned  Value.  The  actual  amount  of  budget  expended  and  aedited  to  the 
program  to  complete  an  authorized  WBS  task. 

Effectiveness.  A  measure  of  the  system  in  terms  of  its  technical 
characteristics.  This  measure,  or  figure-of-merit,  which  will  vary  depending 
on  the  type  of  system  and  its  mission,  may  be  derived  from  a  combination  of 
performance  factors,  weight  and  size,  capacity,  reliability,  maintainability, 
supportability,  quality,  and  so  on. 

Effectiveness  Analysis.  An  analyticai  approach  used  to  determine  how  well  a 
system  performs  in  its  intended  utilization  environment. 

Environment.  The  natural  environment  (weather,  climate,  ocean 
conditions,  terrain,  vegetation,  space  conditions);  combat  environment  (dust, 
fog,  nuclear-chemical-biological);  threat  environment  (effects  of  existing  and 
potential  threat  systems  to  include  electronic  warfare  and  communications 
interception);  operations  environment  (thermal,  shock,  vibration,  power 
variations);  transportation  and  storage  environment;  maintenance 
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environment;  test  environments;  manufacturing  environments  (critical 
process  conditions,  clean  room,  stress)  and  other  environments  (e.g.  software 
engineering  environment,  electromagnetic)  related  to  system  utilization. 

Evolutionary  Acquisition.  An  adaptive  and  incremental  strategy  applicable  to 
high  technology  and  software  intensive  systems  when  requirements  beyond  a 
core  capability  can  generally,  but  not  specifically,  be  defined. 

Exit  Criteria.  Program  specific  accomplishments  that  must  be  satisfactorily 
demonstrated  before  an  effort  Of  program  can  progress  further  in  the  current 
acquisition  phase  or  transition  to  the  next  acquisition  phase.  Exit  criteria  may 
indude  such  factors  as  critical  test  issues,  the  attainment  of  projected  growth 
curves  and  baseline  parameters,  and  the  results  of  risk  reduction  efforts 
deemed  aitical  to  the  dedsion  to  proceed  further.  Exit  ciiteria  supplement 
minimum  required  accomplishments  and  are  spedfic  to  each  acquisition 
phase. 

Facilitate.  To  help  the  process  to  be  free  from  obstades/  to  make  easier.  To  act 
as  the  catalyst  in  process. 

Feasibility  Analysis.  The  early  investigation,  study,  and  determination  of 
possible  techiucal  design  approaches  in  response  to  a  defined  need  for  a  new 
system  configuration.  This  indudes  the  evaluation  and  comparison  of  new 
technologies,  as  well  as  the  accomplishment  of  applied  research  in  areas 
where  additional  knowledge  is  desired. 

Function.  A  task,  action  or  activity  that  must  be  performed  to  achieve  a 
desired  outcome. 

Functional  Analysis.  The  process  of  translating  system-level  requirements 
into  detailed  design  criteria  leading  to  the  development  of  system 
components.  Given  the  definition  of  system  operational  requirements  and 
the  maintenance  concept,  the  next  step  is  to  define  the  system  in  functional 
terms,  identifying  the  'WHATs  in  terms  of  specific  requirements.  This  can  be 
accomplished  through  a  series  of  functional  block  diagrams.  These  functions 
(to  indude  both  operational  and  maintenance  functions)  are  broken  down 
into  sub-functions,  trade-off  studies  are  accomplished  to  determine  the 
HOWs  assodated  with  the  accomplishment  of  the  sub-functions,  and 
resources  are  identified  in  terms  of  human  requirements,  equipment 
requirements,  software,  data,  facilities,  and  so  on.  Again,  this  is  a  top-down 
process  stemming  from  system-levd  requirements  and  leading  to  ihe 
identification  of  spedfic  design  reqtiirements. 
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Functional  Analysis,  [alternate]  Examination  of  a  defined  function  to 
determine  all  of  the  sub-functions  necessary  for  the  accomplishment  of  that 
function.  The  sub-functions  are  then  analyzed  to  determine  constraints 
(depicted  in  a  Control  Hierarchy  Diagram),  sequencing  (shown  in  a 
Functional  Flow  Diagram),  and  subsequently  architecture  and  interfaces 
(depicted  in  a  Functional  Architectme  Diagram). 

Functional  Architecture.  The  arrangement  of  functions  into  logical 
fimctional  domains,  including  both  their  internal  and  external  functional 
interfaces,  as  well  as  their  respective  functional  and  performance 
requirements. 

Functional  Baseline.  The  initially  approved  documentation  describing  a 
system's  or  Cl's  functional,  performance,  interoperability,  and  interface 
requirements  and  the  verification  required  to  demonstrate  the  achievement 
of  those  specified  requirements.  This  baseline  is  normally  placed  under 
Government  control  during  Demonstration  and  Validation. 

Functional  Requirement.  The  necessary  task,  action,  or  activity  that  must  be 
accomplished.  Top-level  functions  are  identified  by  requirements  analysis 
and  subdivided  by  Fmctional  analysis. 

Human  Factors.  The  characteristics  of  system  design  that  relate  to  human 
element  of  the  system.  Considerations  in  design  must  include 
UTiOx,:  ^prometric  factors,  human  sensory  factors,  physiological  factors,  and 
psychological  factors. 

Integrated  Logistic  Support  (ILS).  A  management  function  that  provides  the 
initial  planning,  funding,  and  controls  that  help  to  ensiue  that  die  ultimate 
.consumer  (or  user)  will  receive  a  system  that  will  not  only  meet  performance 
requirements,  but  one  that  can  be  expeditiously  and  economically  supported 
throughout  its  programmed  life  cycle.  The  basic  program  elements  include 
he  initial  planning  for  logistic  support,  the  design  for  supportability,  the 
analysis  and  acquisition  of  the  various  elements  of  support,  and  the 
assessment  of  the  system's  support  capability  in  the  Held. 

Interface  Requirement.  The  functional,  performance,  electrical, 
environmental,  human  and  physical  requirements  and  constraints  that  exist 
at  a  common  boundary  between  two  or  more  functions,  system  elements, 
configuration-items,  or  systems. 
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Interoperability.  The  ability  of  systems,  units,  or  forces  to  provide  services  to 
or  accept  services  from  other  systems,  units,  or  forces  and  to  use  the  services 
so  exchanged  to  operate  effectively  together. 

Item.  A  non-specific  term  used  to  denote  any  product,  including  systems, 
subsystems,  assemblies,  subassemblies,  units,  sets,  parts,  z  ccessories,  computer 
programs  or  computer  software. 

Level  1  (Weapon  System  Level)  of  the  Systems  Hierarchy.  The  top  level  of 
the  system  hierarchy.  Systems  Engineering  activities  primarily  focused  on 
programmatic  issues,  planning  arid  technical  support  to  the  Program 
Manager. 

Level  2  (System  Level)  of  the  Systems  Hierarchy.  The  second  level  of  the 
system  hierarchy.  Systems  engineering  activities  primarily  focused  on 
technical  issues,  including  requirements  allocation  to  the  Inte^ated  Product 
Teams,  interface  management  between  major  segments  of  the  weapon  system 
(e.g.  Air  Vehicle,  Support,  Training,  Production  and  Business  cSperatioiu). 
and  technical  interface  with  the  customer. 

Level  3  (Segment  Level)  of  the  Systems  Hierarchy.  The  third  level  of  the 
system  hierarchy.  Typically  the  upper  level  of  design  activity  for  the  various 
segments  of  the  weapon  system. 

Life  Cycle.  The  planned  life  cycle  of  the  system  from  the  initial  identification 
of  a  need  through  the  retirement  and  phase  out  of  that  system.  It  usually 
includes  the  phases  of  conceptual  design  and  advance  planning,  preliminary 
system  design  (demonstration  and  validation),  detail  design  and 
development  (full  scale  development),  production  and/ or  construction, 
system  operation  (utilization),  sustaining  maintenance  and  support,  .and 
retirement.  Although  the  life  cycle  (and  its  phases)  may  change  because  of 
budgetary  limitations,  the  introduction  of  obsolescence,  and  so  on,  it  is  still 
essential  that  a  life-cycle  approach  be  assumed. 

Life-Cvde  Cost  (LCC).  The  composite  of  all  costs  associated  with  the  activities 
planned  and/or  accomplished  tluoughout  the  system  life  cycle.  This  includes 
the  costs  of  research  and  development,  design,  production/ construction, 
operation  use,  maintenance  and  support,  and  system  retirement. 

Life  Cycle  Cost  (LCC).  [alternate]  The  total  cost  to  the  Government  of 
acquisition  and  ownership  of  that  system  over  its  useful  life.  It  includes  the 
cost  of  development,  acquisition,  support  and,  where  applicable,  disposal. 
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Life  Cycle  Resources.  All  resources  required  for  development, 
manufacturing,  verification,  deployment,  operations,  support,  and  disposal 
(including  by-products)  of  an  item  throughout  its  life  cycle.  Also  included  are 
the  resources  required  for  training  personnel  in  the  operations  and 
maintenance  of  an  item  throughout  its  life  cycle.  These  resources  are 
measured  in  terms  of: 

a.  Time  (e.g.,  time  required  to  develop  and/or  produce  the  item); 

b.  Dollars  (e.g.,  RDT&E,  production,  operations  and  support); 

c.  Manpower  (e.g.,  number  of  people  required  to  develop,  produce, 
support,  and  operate  an  item);  and 

d.  Strategic  materials. 

Low-rate  Initial  Production  (LRIP).  The  production  of  a  system  in  limited 
quantity  to  provide  articles  for  operational  test  and  evaluation,  to  establish  an 
initial  production  base,  and  to  permit  an  orderly  increase  in  the  production 
rate  sufficient  to  lead  to  full-scale  production  upon  successful  completion  of 
operational  testing. 

Maintainability.  The  characteristics  of  design  that  deal  with  the  ease,  accuracy, 
safety,  and  economy  in  the  performance  of  maintenance  actions,  -e  measures 
most  conunonly  associated  with  maintainability  arejmaintenance  elapsed 
times  (Met,  MTTR,  Mpt,  M,  MDT),  maintenance  frequency  factors  (MTBR, 
MTBM),  maintenance  personnel  labor  hour  factors  (MMHIOH,  MMHjMA, 
MMH/Month,  MLHfOH),  and  maintenance  cost  (,$IMA),  When  addressing 
maintenance  elapsed  time  only,  maintainability  can  be  defined  as  the 
probability  that  a  system  can  be  retained  in  or  restored  to  a  satisfactory 
operating  condition,  when  maintenance  is  performed  by  personnel  with 
specified  skills,  using  approved  procedures  and  resources,  at  each  designated 
level  of  maintenance. 

Management  Information  System  (MIS).  A  data  collection,  processing,  and 
handling  capability  that  supports  management  in  the  implementation  of 
program  requirements.  A  prime  objective  for  system  engineering  is  the 
establishment  of  a  good  communications  network  that  will  allow  for  a  rapid 
assessment  of  program  status,  and  for  the  initiation  of  corrective  action  in  an 
expeditious  manner. 

Measure  of  Effectiveness  (MOE).  A  metric  used  to  quantify  the  performance 
of  system  products  and  processes  in  terms  that  describe  the  utility  or  value 
when  executing  customer  missions.  Systems  Engineering  uses  MOEs  in  a 
variety  of  ways  including  decision  metrics,  performance  requirements,  and  in 
assessments  of  expected  performance.  MOEs  can  include  cost  effectiveness 
metrics. 
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Mission  Need.  A  statement  of  operational  capability  required  to  perform  an 
assigned  mission  or  to  correct  an  efficiency  in  existing  capability  to  perform  a 
mission. 

Monitor.  To  check  and  keep  track  of  the  progression  of  an  activity  in  a  non- 
intrusive  manner.  To  make  assessments  as  to  the  adequacy  of  the  resulting 
approach. 

Operational  Effectiveness.  An  OTficE  metric  that  measures  the  overall  degree 
of  mission  accomplishment  of  a  system  when  used  by  representative 
personnel  in  the  environment  planned  or  expected  (e.g.  natural,  electronic, 
threat)  for  operational  employm^t  of  the  system  considering  organization, 
doctrine,  tactics,  survivability,  vulnerability  and  threats.  ITie  operational 
system  that  is  provided  to  users  will  be  evaluated  for  operational 
^cctiveness  by  a  service  OT&E  agency. 

Perform.  To  begin  a  process  or  task  and  carry  it  through  to  completion. 

Performance.  The  charactei  ’stics  of  system  design  that  relate  to  sudi 
measures  as  input-output  requirements,  throughput,  capacity,  size  and 
weight,  range,  accuracy,  power  output,  data  transmitted  per  designated 
increment  of  time,  etc. 

Producibility.  The  characteristics  of  system  design  that  relate  to  the  ease, 
accuracy,  and  economy  associated  with  the  follow-on  manufacture  of  system 
elements  in  multiple  quantities  as  required.  The  objective  is  to  design 
products  that  can  be  easily  produced  in  multiple  quantities,  using 
conventional  manufacturing  processes. 

Requirements  Allocation  Document  (RAD).  A  document  which  contains  all 
technical  requirements  allocated  to  a  particular  product  definition  team.  It 
includes  botli  direct,  i-e.,  contract  specifications,  and  derived.  i.e.,  MDA  self- 
imposed,  requirements.  Derived  requirements  fall  into  two  categories:  those 
allocated  from  other  teams  (such  as  Reliability/Maintainability  requirements) 
and  those  derived  by  the  respective  Subsystem  Manager  for  their  equipment. 

Requirements  Allocation  Matrix  (RAM).  A  document  (in  matrix  form) 
which  relates  contract  specification  paragraphs  to  a  particular  product 
definition  temn  charged  with  the  responsibility  for  ensuring  design 
incorporation  and/or  compliance. 
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Reliability.  The  characteristics  of  design  that  relate  to  the  ability  of  a  system  to 
perform  for  a  designated  period  of  time.  More  specifically,  it  can  be  defined  as 
the  probability  that  a  system  or  product  will  perform  in  a  satisfactdty  manner 
for  a  given  period  of  time  when  used  under  specified  operating  conditions. 
The  measures  of  reliability  include  MTBF,  MTBM  and  MTTF. 

Risk.  A  subjective  assessment  made  regarding  the  likelihood  or  probability  of 
not  achieving  a  specific  objective  by  the  time  established  with  the  resources 
provided  or  requested.  It  also  refers  to  overall  program  risk. 

Risk  Management.  An  organized,  analytic  process  to  identify  what  can  go 
wrong,  to  quantify  and  assess  associated  risks,  and  to  implement  and  control 
the  appropriate  approach  for  preventing  or  handling  each  risk  identified. 

Risk  Management  falternatel.  An  organized  method  for  identifying  and 
measuring  risk,  and  for  selecting  and  developing  options  for  the  handling  of 
risk.  Risk  management  must  be  addressed  in  the  System  Engineering 
Management  Plan  (SEMP),  and  it  includes  the  functions  of  risk  assessment, 
risk  analysis,  and  risk  abatement. 

Risk  Management  Plan.  Description  of  the  risk  management  program  that 
describes  the  approach  and  activities  for  risk  management.  The  technical  risk 
management  plan  is  an  essential  part  of  the  SEMP. 

£up.portability.  The  characteristics  of  system  design  that  deal  with  the  ability 
of  a  system  to  be  supported  in  an  effective  and  economic  manner.  These 
characteristics  pertain  not  only  to  the  prime  elements  of  the  system,  but  to  the 
design  of  test  and  support  equipment,  the  supply  support  capability,  training 
equipment,  facilities,  maintenance  software,  and  soon.  Many  of  the  principles 
of  r^ability,  maintainability,  and  human  factors  are  included. 

Specification.  A  document  prepared  to  support  acquisition  and  life  cycle 
management  that  clearly  and  accurately  describes  essential  technical 
requirements  and  verification  procedures  for  items,  materials  and  services. 
When  invoked  by  a  contract  it  is  legally  enforceable  and  its  requirements  are 
contractually  binding. 

Specification  Tree.  The  hierarchical  depiction  of  all  the  specifications  needed 
to  control  the  development,  manufacture  and  integration  of  items  in  the 
transition  from  customer  needs  to  the  complete  set  of  system  products  and 
processes  that  satisfy  these  needs. 
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Statement  of  Work  (SOW).  The  non-specification  work  tasks  to  be  completed 
by  the  contractor. 

Subsystem.  A  grouping  of  items  satisfying  a  logical  group  of  functions  within 
a  particular  system. 

System.  A  set  of  components  working  together  with  the  common  objective 
of  performing  a  function  in  response  to  a  designated  need.  A  system 
constitutes  a  complex  set  of  resources  integrated  so  as  to  fulHll  a  deHned 
mission  scenario.  Such  resources  may  take  the  form  of  human  beings, 
materials,  equipment,  software,  facilities,  data,  and  so  on.  The  system  must 
have  purpose,  it  must  be  functional,  be  able  to  respond  to  some  identified 
need,  and  it  should  be  able  to  achieve  its  overall  objective  in  a  cost-effective 
manner. 

System  Analysis.  An  on-going  iterative  analytical  process,  induded  as  part  of 
the  system  engineering  process,  involving  the  evaluation  of  design 
approaches,  the  accomplishment  of  trade-off  studies,  and  so  on.  System 
andysis  is  accomplish^  through  the  appropriate  use  of  various  operations 
research  methods  to  assist  in  problem  resolution  (simulation,  queuing 
theory,  linear  and  dynamic  programming,  networking,  etc.). 

Systems  Engineering.  The  effective  application  of  sdentific  and  engineering 
efforts  to  transform  an  operational  neki  into  a  defined  system  coithguration 
through  the  top-down  iterative  process  of  requirements  definition,  fimcdonal 
analysis,  allocation,  synthesis,  design  optimization,  test,  and  evaluation.  It 
involves  the  design  engineering  process  of  bringing  a  system  into  being,  with 
emphasis  on  an  integrated,  top-down,  life-cyde  approa^. 

Systems  Engineering  Detailed  Schedule  (SEDS).  The  detailed,  task  oriented 
schedule  of  the  work  efforts  required  to  support  the  events  and  tasks 
identitied  in  the  SEMS.  The  SEDS  is  used  to  track  day-to-day  progress  and 
indudes  the  continual  assessment  of  the  technical  parameters  required  to 
support  each  SEMS  task/event. 

System  Engineering  Management.  The  management  activities  necessary  for 
the  implementation  of  system  engineering  requirements.  This  indudes  the 
initial  planzung,  organization  for  system  engineering,  and  die  on-going 
program  evaluation  and  control  activities  to  ensure  that  system  engineering 
objectives  are  met. 
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System  Engineering  Management  Plan  (SEMP).  The  principal  management- 
oriented  document  covering  the  implementation  of  system  engineering 
program  requirements.  This  plan  is  developed  during  the  conceptual  design 
phase  of  a  .  program,  includes  the  results  of  some  advanced  planning,  and 
leads  into  the  requirements  for  the  subsequent  phases  of  system  acquisition. 

Systems  Engineering  Management  Plan  (SEMP).  [alternate]  A  comprehensive 
document  that  describes  how  the  fully  integrated  engineering  effort  will  be 
managed  and  conducted. 

Systems  Engineering  Master  Schedule  (SEMS).  A  compilation  of  key 
accomplishments  requiring  successful  completion  to  pass  identified  events. 
Accomplishments  include  major  and  critical  tasks,  activities  and 
demonstrations,  with  associated  accomplishment  criteria.  Events  include 
technical  reviews  and  audits,  demonstration  milestones,  and  decision  points. 
Successful  completion  is  determined  by  the  measurable  criteria  defined  for 
each  accomplishment.  Examples  of  the  criteria  include  completed  work 
efforts  and  technical  parameters  used  in  TPM.  Quantitative  inputs  into 
program  decision  points. 

Systems  Engineering  Process.  A  compreheiwive,  iterative,  problem  solving 
process  that  is  used  to;  a)  transform  validated  customer  needs  and 
requirements  into  a  life-cycle  balanced  solution  set  of  system  product  and 
process  designs;  b)  generate  information  for  decision  makers;  and  c)  provide 
information  for  the  next  acquisition  phase.  The  problem  and  success  criteria 
are  defined  tnrough  requirements  analysis,  functional  analysis,  and  system 
analysis  and  control.  Alternative  solutions,  evaluation  of  those  alternatives, 
selection  of  the  best  life-cycle  balanced  solution,  and  the  description  of  the 
solution  through  the  design  package  are  accomplished  through  synthesis  and 
system  evaluation  activities. 

System  Integration.  Involves  the  technical  integration  of  system  elements  as 
the  design  and  development  effort  progresses,  ^ong  with  ^e  integration  of 
the  various  design  and  supporting  disciplines  into  the  overall  design  effort 
from  a  managerial  perspective.  Later  during  detail  design  and  development, 
the  integration  process  often  involves  a  bottom-up  approach  relative  to  the 
combining  of  the  various  system  components  into  subassemblies, 
subassemblies  into  assemblies,  assemblies  into  units,  until  a  totally  integrated 
system  is  functioning  in  accordance  with  the  initially  specified  requirements. 

System  Specification.  The  top-level  technical  document  that  defines  the  basic 
requirements  for  system  design  and  development. 
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System  Synthesis.  The  combining  and  structuring  of  components  in  sudt  a 
way  as  to  represent  a  feasible  system  configuration.  This  may  be  accomplished 
on  a  number  of  occasions  throughout  the  system  design  and  development 
process,  and  the  particular  configuration  structured  may  not  reflect  tiKe  final 
design  approach.  In  essence,  one  needs  to  define  n  configuration  in  such  a  way 
that  it  can  be  evaluated. 

Technical  Performatrce  Measurement  CIPMl.  The  continuing  verification  of 
the  degree  of  anticipated  and  actual  achievement  of  technical  parameters. 
TPM  is  used  to  identify  and  flag  the  importance  of  a  design  d^i^dency  that 
might  jeopardize  meeting  a  system  level  requirement  that  has  been 
determined  to  be  critical.  Measured  values  that  fall  outside  of  an  established 
tolerance  band  require  proper  corrective  actions  to  be  taken  by  managemeici:. 

Technical  Performance  Measures  (TPMs).  Those  measures  of  the  system,  or 
of  program  activities,  that  are  considered  as  being  critical  for  the  successful 
accomplishment  of  system  engineering  objectives.  Specific  quantitative 
parameters,  reflecting  the  basic  design  characteristics  of  the  system,  are 
specified  initially  in  the  System  Spe^cation  (Type  "A'O.  Th^,  as  design  and 
development  progresses,  these  factors  need  to  hx  integrate  into  file 
periodically  scheduled  program/design  review  process  for  comparison  against 
the  initially  specified  requirements.  Finally,  an  evaluation  of  the  system,  in 
terms  of  compliance  with  these  requirements,  is  accomplished  through  the 
final  system  evaluation  and  test  activity.  The  objective  is  to  identify  ^e 
critical  factors  that  are  performance  related. 

Technical  Reviews.  A  series  of  systems  engineering  activities  by  which  the 
technical  progress  of  a  program  is  assessed  relative  to  its  technical  or 
contractual  requirements.  Conducted  at  logical  transition  points  in  the 
development  effort  to  reduce  risk  by  identifying  and  correcting  problems  or 
issues  resulting  from  the  work  completed  before  the  program  is  disrupted  or 
delayed.  Provides  a  method  for  the  contractor  and  the  Government  to 
determine  tliat  the  development  of  a  system  and/or  configuration  item  and 
its  documentation  have  met  contract  requirements.  Includes  incremental 
reviews  (functional,  subsystem  and  interim  system)  and  major  system  level 
technical  reviews. 

Test  and  Evaluation  Master  Plan  (TEMP).  A  key  planning  doounent, 
developed  during  the  conceptual  design  and  advance  planning  phase, 
covering  the  proposed  integration  and  testing  requirements  for  the  system  as 
an  entity.  A  total  integrated  test  approach  is  essential. 
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Timeline  Analysis.  Analytical  task  conducted  to  determine  the  time 
sequencing  between  two  or  more  events.  Examples  of  timelines  include: 

a,  a  schedule  line  shewing  key  dates  and  planned  events; 

b,  a  mission  flight  path  identifying  when  and  where  planned  changes 
in  course  and  velocity  <^ke  place:  and 

c,  a  portion  of  an  engagement  profile  detailing  time  based  position 
changes  between  a  weapon  and  its  target. 

Total  quality  management  (TOM).  A  total  integrated  management  approach 
that  addresses  s5'Etem/product  quality  during  all  phases  of  the  system  life  cycle 
and  at  each  levd  m  the  overall  system  hierarchy.  It  provides  a  "before-the- 
fact"  orientation  to  quality/  and  it  focuses  on  system  design  and  development 
activities/  as  well  as  production/  manufacturing/  assembly/  construction/  and 
related  functions.  It  includes  activities  associate  with  the  "design  for 
produdbility  "  quality  engineering/  qudity  control,  statistical  process  control 
(SPC),  quality  assurance,  and  supplier  ev^uation  and  control. 

Work  Breakdown  Structure  (WBS).  A  product-oriented  family  tree 
composed  of  hardware,  software,  services,  data  and  fadlities  whicl;  result 
from  systems  engineering  efforts  during  the  development  and  production  of 
a  defeiise  materiel  item,  and  which  completely  defines  the  program.  Displa3rs 
and  defines  the  prcduct(s)  to  be  developed  or  produced,  and  relates  the 
elements  of  work  to  be  accomplished  to  each  other  and  to  the  end  product. 
Provides  structure  for  guiding  multi-disdplinary  team  assignment  and  cost 
tracking  and  control. 

Work  Breakdown  Structure  (WBS)  [alternate]  A  prodiict-orienteJ  family  tree 
that  leads  to  the  identification  of  activities,  functions,  program  tasks,  sub¬ 
tasks,  and  work  packages  that  must  be  peiiormed  for  Uie  successful 
completion  of  a  given  program.  It  displays  and  defines  the  system  to  be 
developed,  and  portrays  all  of  the  dements  of  work  to  be  accomplished.  There 
are  "Suimnaiy  Work  Breakdown  Structures"  (SWBSs)  used  to  sliow  the  top 
three  levels  of  work  broken  out  in  a  summary  manner,  and  "Contract  Work 
Breakdown  Str  uctures  (CWBSs)  used  for  the  purposes  of  contract  negotiation. 
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2.0  ACRONYMS  AND  ABBREVIATIONS 
Encountered  in  the  Engineering  of  Military  Avionics 

ACAT  Acquisition  Category  (Nav}') 

ABL  Asseukbly  Breakdown  List 

ACCM  Advanced  Concepts  Cost  Model 

ADM  Acquisition  Decision  Memorandum/  also  Advanced  Development 
Model 

ADPLS  Automated  Drawing  Parts  List  System 

Ail  Aileron 

ANOVA  Analysis  of  Variance 

ASIRD  Avionics  System  Integration  Requirements  Document 

ATP  Acceptance  Test  Procedure 

ATF  Advanced  Tactical  Fighter 

AZ  Azimuth 

BIT  Built  In-Test 

BITE  Built  In  Test  Equipment 

BDA  Bomb  Damage  Assessment 

CAT-S  Computer-aided  Acquisition  Logistics  Support 

CAP  Combat  Air  Patrol 

CASE  Computer  Aided  Software  Engineering 

CCB  Configuration  Control  Board 

Ca  Candidate  Configiuation  Item 

CDR  Critical  Design  Review 

CDRL  Contract  Data  Requirements  List 

CDSR  Contract  Data  Status  Report 

GE  Concept  Exploration 

CED  Concept  Exploration  &  Definition 

Q  Consequences  of  Failure 

CFE  Coiitractor  Furnished  Equipment 

CHD  Control  Hierardiy  Diagrarr 

Q  Configuration  Item 

CmS  Contractor  Integrated  Technical  Information  Services 
CLIN  Contract  Line  Item 
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CM  Configuration  Management 

CMRS  Calibration  Measurements  Requirements  Summary 

CNI  Communication,  Navigation,  Identification 

C&RS  Control  &  Release  System 

COEA  Cost  &  Operational  Effectiveness  Analysis 

COTS  Commercial  Off-The-Shelf 

CS  Configuration(s)  Synthesis 

CSC  Computer  Software  Component 

CSC!  Computer  Software  Configuration  Item 

C/SCS  Cost/Schedule  Control  System 

C/SCSC  Cost/Schedule  Control  System  Criteria 

CSE  Chief  Systems  Engineer 

CWBS  Contract  Work  Breakdown  Structure 

DCN  Drawing  Change  Notice 

DAB  Defense  Acquisition  Board 

DCP  Decision  Coordinating  Paper 

DDM  Design  Decision  Memo 

DEM/VAL  Demonstration  &  Validation 

D1  Data  Item 

DID  Data  Item  Description 

DoD  Department  of  Defense 

DODD  Department  of  Defense  Directive 

DODI  Department  of  Dtsfense  Instruction 

DTC  Design  To  Cost 

D/V  Demonstration  &:  Validation 

ECP  Engineering  Change  Proposal 

ECS  Environmental  Control  System 

EDA  Electronic  Design  Automation 

EDDP  Engineering  Design  Doaunentadon  Procedures 

EDM  Engineering  Development  Model 

EL  Elevation 

EMC  Electromagnetic  Compatibility 

EMD  Engineering  &  Manufacturing  Development 

EM  Electromagnetic  Interference 
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BO  Electro-Optics 

ESP  Engineering  Standard  Practice 

EW  Electronic  Warfare 

FA  Functional  Analysis 

FAD  Functional  Architectiure  Diagram 

FFD  Functional  Flow  Diagram 

FFRR  First  Flight  Readiness  Review 

FOR  Functional  Qualification  Review 

GFE  Government  Furnished  Equipment 

HDBK  Handbook 

Ff/W  Hardware 

HWCI  Hardware  Configuration  Item 

ICD  Interface  Control  Document 

ICS  Interface  Control  Sheet 

ICWG  Interface  Control  Working  Group 

IDP  Individual  Training  Plan 

IFFC  Integrated  Flight/Fire  Control 

ILS  Integrated  Logistics  Support 

ILSP  Integrated  Logistics  Support  Plan 

IOC  Initial  Operating  Capability 

IPD  Integrated  Product  Development 

DPT  Integrated  Product  Teams 

IR  Infrared 

I&R  Interchangeability  &  Replaceability 

IRS  Interface  Requirements  Specification 

IWARS  Interacfive  Warfare  Simulation 

LOC  Life  Cycle  Cost 

LH  Left  Hand 

LPl  Low  Probability  of  Intercept 

LRIP  Low  Rate  Initial  Production 

LSA  Logistics  Support  Analysis 

LSAR  logistics  Support  Analysis  Records 

LSC  Logistics  Support  Cost 

MFD  Multifunction  Display 
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MIL  Military 

MIL-STD  Military  Standard 

MIMIC  Microwave  and  Milimeterwave  Integrated  Circuits 

MNS  Mission  Needs  Statement 

MOE  Measure  of  Effectiveness 

MP  Maintainability  Plan 

MRF  Multiroie  Fighter 

MS  Acquisition  Milestone 

MSRB  Management  Safety  Review  Board 

MTBF  Mean  Time  Between  Failures 

MTBM  Mean  Time  Between  Maintenance 

MTBO  Mean  Time  Between  Overhaul 

MTTF  Mean  Time  To  Repair 

NOR  Notice  Of  Revision 

OJT  On-The-Job  Training 

0/5  Operations  &  Support 

ORD  Operational  Requirements  Document 

P/D  Production  &  Deployment 

PCA  Physical  Configuration  Audit 

PDR  Preliminary  Design  Review 

PERT  Performance  Evaluation  Review  Technique 

P^  Pre-Plaimed  Product  Improvement 

Pf  Probability  of  Failure 

PM  Program  Manager 

PMO  Program  Management  Office 

PPM  Program  Performance  Measure 

PRR  Production  Readiness  Review 

PSC  Preferred  System  Concept 

PSCN  Proposed  Specification  Change  Notice 

PSP  Programmable  Signal  Processor 

QFD  Quality  Function  Deployment 

RA  Requirements  Analysis 

RAD  Requirements  Allocation  Document 

RAM  Requirements  Allocation  Matrix 
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RAS 

Requirements  Allocation  Sheet  1 

•\  9‘. 

p  '  • 

RF 

Radio  Frequency  _ 

S 

RH 

Right  Hand  | 

I-  . 

R&D 

Research  and  D  iveiopment 

I  ■' 

R&M 

Reliability  and  Maintainability  | 

i  • 

5  ■ 

RFP 

Request  for  Proposal 

1- 

RP 

Reliability  Plan  ■ 

4 

* 

f 

SAM 

Surface-to-Air  Missile  * 

ir 

SBD 

Schematic  Slock  Diagram  jH 

i'. 

SCN 

Specification  Change  Notice  B 

f: 

f 

SDD 

System  Design  Document 

1  ■ 

SDR 

System  Design  Review  H 

• 

SE 

Systems  Analysis,  Control  tg.  Evaluation 

■i 

$ 

SECDEF 

Secretary  of  Defense  | 

I:.,: 

SEDS 

Systems  Engineering  Detailed  Schedule 

B 

1 

SEMP 

Systems  Engineering  Management  Flan  ■ 

»  ' 

1 

SEMS 

Systems  Engineering  Master  Schedule  ■ 

5 

SEP 

Specialty  Engineering  Plans  m 

1 

1  " 

SERD 

Support  Equipment  Recommendation  Data  B 

1  * 

1 

y 

1"  . 

SLDA 

System  Level  Design  Automation 

V 

1  ; 

SMS 

Stores  Management  System  B 

• 

I"  . 

SOW 

Statement  Of  Work 

t  '  • 

‘■f  m 
>1-  . 

SPC 

Statistical  Process  Control  j| 

SRR 

System  Requirements  Review 

l'  * 

S'' 

SSDD 

System/Segment  Design  Document  ■ 

■  * 

SSEMP 

System  Security  Engineering  Management  Plan  ■ 

C'  '■ 

SSPP 

System  Safety  Program  Plan  m 

■'V 

i  ■ 

ti  .  V. 

SSR 

Software  Specification  Review  B 

1": 

SSS 

System/Segment  SpeciEcation 

1  ' 

Stab 

Stabilizer  | 

S/W 

Software 

TCM 

Technical  Coordination  Meeting  ||| 

i 

i  •■ 

TPM 

Technical  Performance  Measurement 

1  . 

1 

TQM 

Total  Quality  Management  | 

i  "  ■ 

a 

PlgeA20  ® 

1 

TRR 

UPC 

USAF 

USD(A) 

USN 

VECP 

VHDL 

VHSIC 

VLSI 

VMS 

VOC 

VR 

WBS 


Volume  2;  Avionics  Systems  Engineering 
Appendix  A 


Test  Readiness  Review 

Unit  Production  Cost 

United  States  Air  Force 

Under  Secretary  of  Defense  for  Acquisition 

United  States  Navy 

Value  Engineering  Change  Proposal 

VHSIC  Hardware  Description  Language 

Very  High  Speed  Integrated  Circuits 

Very  Large  Scale  Integrated  Circuits 

Vehicle  Management  System- 

Voice  of  the  Customer 

Vai  lability  Reduction 

Work  Breakdown  Structiure 
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